Closed jasonm23 closed 3 weeks ago
Hi there, thanks for the issue!
The convention in Python is generally not to do this -- instead documentation (and these days perhaps static type annotations) are instead the way to document what types are expected, and it's expected that users of an API read its API documentation, especially if they encounter an error.
(For what it's worth as well, the type of schemas is Mapping[str, JSONDeserialized] | bool
for "official" JSON Schema dialects -- note the bool -- but the type of schemas in the library is actually Any
, as users are free to create dialects where schemas can be other types).
Again, thanks for the offer nonetheless, and feedback is definitely always welcome, but yeah, will politely decline the specific proposal.
The error response should make sense, at the moment its wildly off topic.
Generally that's to be expected if you provide something that isn't the right type, your first response as a user there (for any hypothetical user running into such an error, not you specifically) should always be checking to see as a user that you've done so correctly by checking the docs, not for every library to insert runtime type checking.
The
jsonschema.validate()
function currently doesn't perform any type checking on its arguments.This can lead to unexpected behavior when passing schema and instance strings. Which, let's be fair, is a reasonably intuitive thing to do.
To improve user experience and prevent potential errors, it would be helpful to add a type check for the schema and instance arguments in
jsonschema.validate()
(and likely other functions in the module)Specifically:
json.loads
in case of stringThe current errors for this are a mess and point towards the meta schema, which is completely unrelated, or if I'm being charitable, a very verbose and obtuse way of saying, "Hey! this ain't no dict!"
I feel this change would make the
jsonschema.validate()
function (and others) more robust and easier to use, reducing the likelihood of unexpected errors, wasted time and improving overall usability.I hope this proposal will be considered and implemented in future versions of
jsonschema
.