Skip to content

What is the "right way" to annotate a wsgi application with middlewares? #7585

Description

@sirosen

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:

def make_flask_app() -> flask.Flask: ...

def apply_middlewares(app: Flask):
    profdir = os.getenv("WSGI_PROFILE_DIR")
    if profdir:
        return werkzeug.middleware.profiler.ProfilerMiddleware(app, profile_dir=profdir)
    return app

def make_app():
    app = make_flask_app()
    return apply_middewares(app)

So what is the return type of apply_middlewares?

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.

Activity

  1. JelleZijlstra commented on Apr 4, 2022

    @JelleZijlstra
    Member

    It should be safe to use the _typeshed.wsgi types, see https://github.com/python/typeshed/tree/master/stdlib/_typeshed for documentation.

  2. sirosen commented on Apr 4, 2022

    @sirosen
    ContributorAuthor

    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?

  3. JelleZijlstra commented on Apr 4, 2022

    @JelleZijlstra
    Member

    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.

  4. srittau commented on Apr 4, 2022

    @srittau
    Collaborator

    Please see bpo-42012. Maybe a core developer (wink wink) could comment on this.

  5. sirosen commented on Apr 15, 2022

    @sirosen
    ContributorAuthor

    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! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions