Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow formats for non-string types #86

Open
Stranger6667 opened this issue Aug 17, 2021 · 1 comment
Open

Allow formats for non-string types #86

Stranger6667 opened this issue Aug 17, 2021 · 1 comment

Comments

@Stranger6667
Copy link
Contributor

As per Draft 4 and Draft 7 validation docs:

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-jsonschema raises an error if a strategy produces a non-string value.

What do you think about removing this restriction?

@Zac-HD
Copy link
Member

Zac-HD commented Aug 18, 2021

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants