-
Notifications
You must be signed in to change notification settings - Fork 575
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
Check for annotated-types
constraints in st.from_type(Annotated[T, ...])
#3356
Comments
A more detailed breakdown of the tasks involved:
Other constraints: unpack hypothesis/hypothesis-python/src/hypothesis/strategies/_internal/types.py Lines 369 to 377 in 47b35ce
|
I've started an implementation of this, and I have a couple questions:
I'm don't have much knowledge on how filter rewriting works, but is there a way to check that How should we handle constraints that are incompatible with each other/with the annotated type? e.g. |
How to check that filter-rewriting works: trust that https://github.com/HypothesisWorks/hypothesis/blob/master/hypothesis-python/tests/cover/test_filter_rewriting.py would surface any problems 😁
Hmm, this is somewhat tricky - the decision about whether to return I think in this case I'd just translate to filters, as the easy-to-implement approach. That means:
|
Ok I see, I'll soon open a draft PR so that progress can be tracked.
By register a callback you mean using this function? hypothesis/hypothesis-python/src/hypothesis/strategies/_internal/types.py Lines 703 to 706 in 058420a
Ideally I will try to build strategies in a "smart" way, and avoid using filters when no filter rewriting is available (e.g. What's challenging is that I could manually build the strategies with the correct kwargs (e.g. |
Let's start simple, and only include filters in the initial version. If sometimes that means users get After we've shipped the logically correct version, we can look at improving performance in common cases. |
At PyCon 2022 I helped start https://github.com/annotated-types/annotated-types - so it would be nice to support these new constraints once we finalize the upstream release! The key idea is that we can iterate through the constraints, and derive callables which we then use as filters on the strategy that we resolved for the annotated type.
Filter-rewriting will then make numeric bounds as efficient as is practically possible at runtime (though see #3134 / b4c4161 / #3479 for strings). For example:
@adriangb @samuelcolvin FYI 😁
The text was updated successfully, but these errors were encountered: