You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A format attribute can generally only validate a given set of instance types. If the type of the instance to validate is not in this set, validation for this format attribute and instance SHOULD succeed.
Newer drafts are more clear on this matter. For example, Draft 2020-12 additionally provides this:
All format attributes defined in this section apply to strings, but a format attribute can be specified to apply to any instance types defined in the data model defined in the core JSON Schema.
Even though, that the supported drafts (4, 6, 7) are a bit vague about instance types, I think that it could be treated as they allow non-string instances. The Open API spec explicitly uses it with int32, float, and other formats that are applicable for non-string types.
jsonschema also supports arbitrary types for its format checkers, at least based on its docstring:
Check whether the instance conforms to the given format.
Arguments:
instance (*any primitive type*, i.e. str, number, bool):
The instance to check
Currently, hypothesis-jsonschemaraises an error if a strategy produces a non-string value.
What do you think about removing this restriction?
The text was updated successfully, but these errors were encountered:
Hmm. I think it would actually be cleaner to hard-code support just for the OpenAPI formats:
int32 and int64 have clear interpretations in terms of setting type: integer as well as the min_value and max_value; that can be handled in canonicalisation
All floats are double by default, but we can pass width=32 for floats with format: float
The byte and binary string formats can be added to our existing lookup table (the others already work)
Do you know of any cases where users would want to define custom formats for non-string types?
(I also note that draft-2020-12 allows any type for format, but also forbids reliance on tools handling custom formats unless by agreement - so I'm technically already conforming. And the jsonschema library doesn't look like it supports formats for arrays or objects.)
As per Draft 4 and Draft 7 validation docs:
Newer drafts are more clear on this matter. For example, Draft 2020-12 additionally provides this:
Even though, that the supported drafts (4, 6, 7) are a bit vague about instance types, I think that it could be treated as they allow non-string instances. The Open API spec explicitly uses it with
int32
,float
, and other formats that are applicable for non-string types.jsonschema
also supports arbitrary types for its format checkers, at least based on its docstring:Currently,
hypothesis-jsonschema
raises an error if a strategy produces a non-string value.What do you think about removing this restriction?
The text was updated successfully, but these errors were encountered: