-
-
Notifications
You must be signed in to change notification settings - Fork 151
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
Should quart.make_response
be typed as returning Response
?
#288
Comments
I think the route should be typed as returning a |
Yes, that works! However that's a lot to type. And it does not apply to def apply_caching(response: Response) -> ResponseReturnValue:
... But it works, so I'm happy to close this if you want to. |
pquentin
added a commit
to pquentin/urllib3
that referenced
this issue
Apr 4, 2024
As suggested in pallets/quart#288
pquentin
added a commit
to urllib3/urllib3
that referenced
this issue
Apr 4, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce
With the following Quart app:
mypy fails because
make_response
does not return aResponse
:Expected result
I would expect validation to pass. Indeed, the equivalent Flask app passes validation:
Workarounds
return "<p>Hello, World!</p>"
and mark the return type asstr
. But figuring out the right type is tiring, is a maintenance burden and arguably introduces unnecessary variation in the code.return quart.Response("<p>Hello, World!</p>")
but it quickly breaks for more complex types. I spent a lot of time trying to understand whyquart.Response({"headers": "foo", "params': "bar"})
was returning "headersparams"!quart.typing. ResponseTypes
. This is what I'm doing right now in the urllib3 tests (Migrate TestPoolManager to Hypercorn urllib3/urllib3#3193) but I would rather useResponse
.Environment
The text was updated successfully, but these errors were encountered: