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

Annotate decorators with ParamSpec #3212

Closed
wants to merge 7 commits into from

Conversation

gjoseph92
Copy link

@gjoseph92 gjoseph92 commented Jan 11, 2022

This uses typing.ParamSpec on composite and functions. 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.

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
Copy link
Author

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?

Copy link
Member

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
Copy link
Author

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?

Copy link
Member

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.

@Zac-HD
Copy link
Member

Zac-HD commented Jan 17, 2022

Hey @gjoseph92 - unfortunately it looks like mypy isn't up for this just yet, even when I tried taking out st.functions() improvements in #3219.

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!

@Zac-HD Zac-HD closed this Jan 17, 2022
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

Successfully merging this pull request may close these issues.

2 participants