We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
vary_on_headers
Noticed this while reviewing #1339. The vary_on_headers decorator doesn't preserve the type (arguments and return) when used on a function.
The text was updated successfully, but these errors were encountered:
Hey @intgr @adamchainz! Wanted to ask a few things about this one. In https://github.com/typeddjango/django-stubs/blob/master/django-stubs/views/decorators/vary.pyi , what does the definition of vary_on_headers here imply? Are we overriding the decorator funciton here? One approach I could think of is wrapping the whole definition into functools.wraps decorator. Not sure how good that would be or whether it would even work or not? Would appreciate your feedback!
functools.wraps
Sorry, something went wrong.
functools.wraps doesn't help AFAIK. I could be wrong.
There are lots of examples of decorators already, I think you can look at require_http_methods which behaves similarly.
require_http_methods
Here's mypy documentation on type hinting decorators: https://mypy.readthedocs.io/en/stable/generics.html#declaring-decorators
Please don't @ particular people on issues, those who have notifications will notice.
I have raised a PR ( #1370 ) for this. For a more accurate type annotation, I utilised a parameter specification (ParamSpec). Kindly review.
Successfully merging a pull request may close this issue.
What's wrong
Noticed this while reviewing #1339. The
vary_on_headers
decorator doesn't preserve the type (arguments and return) when used on a function.The text was updated successfully, but these errors were encountered: