-
Notifications
You must be signed in to change notification settings - Fork 588
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
Annotate decorators with ParamSpec
#3212
Conversation
This uses `typing.ParamSpec` on `composite`, `functions`, and `given`. This should allow type-checkers and IDEs to infer the signatures of functions returned by these decorators. For `composite` and `functions`, I find this especially helpful.
Probably won't work, but let's see
`given` does consume the function's arguments (obviously), and ParamSpec isn't sophisticated enough to indicate that the _number_ of arguments to `given` is equal to the _number_ of arguments consumed from the wrapped function, even though the types of arguments given to `given` don't match the types of arguments of the function (you'd need to be able to unpack the type argument from the parametrized type somehow). This was the least important one to annotate anyway IMO.
@@ -0,0 +1,5 @@ | |||
RELEASE_TYPE: minor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't sure whether to consider this minor or patch. On one hand, it only touches annotations and has no effect at runtime, so should probably be considered patch. However, if anyone is running mypy on their code which uses Hypothesis, the increased strictness of the annotations could cause mypy to fail code that passed before, which could be considered a breaking change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's honestly a borderline case, but in borderline cases I prefer to err on the side of minor
- we make no compatibility guarantees about type annotations, but it's still polite to make version constraints easy if we think users might want them.
@@ -43,6 +43,7 @@ | |||
from uuid import UUID | |||
|
|||
import attr | |||
from typing_extensions import Concatenate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think typing_extensions
is a requirement of Hypothesis, and I'm not sure if you want to make it one. Any ideas how to handle this? Anything I could reuse from strategies/_internal/types.py
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not a requirement, and I'd like to keep it optional - in which case I think the best option is to try importing ParamSpec (from typing, then typing_extensions); and then have two function definitions behind an if ParamSpec is not None:
/else
condition. Probably makes sense to write this as a very simple wrapper for an unannoted _
-prefixed function so we're at least not duplicating the logic.
python/mypy#3737 is still unfortunate :(
Hey @gjoseph92 - unfortunately it looks like mypy isn't up for this just yet, even when I tried taking out Thanks so much for trying this out though - it's a feature I'm really really keen to have, and I would love a new PR as soon as mypy supports ParamSpec properly! |
This uses
typing.ParamSpec
oncomposite
andfunctions
. This should allow type-checkers and IDEs to infer the signatures of functions returned by these decorators. Forcomposite
andfunctions
, I find this especially helpful.