You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
What is the "right way" to annotate a wsgi application with middlewares? #7585
I'm working with flask and werkzeug, and trying to figure out how to improve some of my typing (mypy --disallow-untyped-defs). When I look at the types from typeshed for wsgiref, and how werkzeug handles this, I find things that are a bit confusing. This question is only somewhat flask/werkzeug specific, it mostly pertains to typeshed -- I'm happy to repost or cross-post in werkzeug if that seems better.
Here's something similar to what I have today, partially annotated:
Looking around, it seems like this is _typeshed.wsgi.WSGIApplication. But that's in _typeshed -- is it safe to import it at type-checking time? Could it be renamed in the future? werkzeug already does this:
if TYPE_CHECKING:
from _typeshed.wsgi import WSGIApplication
Is this safe for me to do too? I'm going to probably do this for today but it would be great to either know that the name is stable or to find a better way.
Concretely, the type above is just Flask | ProfilerMiddleware today. But any other middleware will (spuriously) be flagged as changing the type if the code changes. So WSGIApplication is really much preferable.
I'd really like to see WSGIApplication (and some of the other stuff, like StartResponse) available as types that I can use at typing time. Does this require additions of some of these types as protocols to the stdlib? I'm more than happy to work on this, if it's not already in progress.
Ah, I hadn't found that readme -- and particularly the API stability note. Thank you!
That solves my scenario nicely. It would still be nice to get these types into wsgiref. I'll try to remember to file something on cpython after the github issues migration. Should this be left open or closed?
I'd like to hear if @srittau has more input here. We've talked in the past about making _typeshed importable at runtime so you don't need if TYPE_CHECKING.
I just looked to see if I could maybe help with this work, and I see python/cpython#32335 already open!
As the OP, I think it's reasonable to close this and am doing so now. It will take a while for most people to be able to use the types in the stdlib, but things are on a good course.
Every time I try to help with typeshed and typing it's a pleasure. Thanks so much to everyone involved! 🎉
Activity
JelleZijlstra commentedon Apr 4, 2022
It should be safe to use the
_typeshed.wsgitypes, see https://github.com/python/typeshed/tree/master/stdlib/_typeshed for documentation.sirosen commentedon Apr 4, 2022
Ah, I hadn't found that readme -- and particularly the API stability note. Thank you!
That solves my scenario nicely. It would still be nice to get these types into
wsgiref. I'll try to remember to file something on cpython after the github issues migration. Should this be left open or closed?JelleZijlstra commentedon Apr 4, 2022
I'd like to hear if @srittau has more input here. We've talked in the past about making
_typeshedimportable at runtime so you don't needif TYPE_CHECKING.srittau commentedon Apr 4, 2022
Please see bpo-42012. Maybe a core developer (wink wink) could comment on this.
sirosen commentedon Apr 15, 2022
I just looked to see if I could maybe help with this work, and I see python/cpython#32335 already open!
As the OP, I think it's reasonable to close this and am doing so now. It will take a while for most people to be able to use the types in the stdlib, but things are on a good course.
Every time I try to help with typeshed and typing it's a pleasure. Thanks so much to everyone involved! 🎉