This follows a similar structure in Werkzeug and allows for async
based IO projects, specifically Quart, to base themselves on
Flask.
Note that the globals, and signals are specific to Flask and hence
specific to Flask's IO. This means they cannot be moved to the sansio
part of the codebase.
This is preperation for refactoring the files so that there are sansio
and flask specific versions. This structure follows the Werkzeug
structure/pattern.
This ensures that a child's subdomain prefixs any parent subdomain
such that the full domain is child.parent.domain.tld and onwards with
further nesting. This makes the most sense to users and mimics how
url_prefixes work (although subdomains suffix).
* Add a missing setupmethod decorator
* Improve the decorator typing
This will allow type checkers to understand that the decorators return
the same function signature as passed as an argument. This follows the
guidelines from
https://mypy.readthedocs.io/en/stable/generics.html#declaring-decorators.
I've chosen to keep a TypeVar per module and usage as I think
encouraged by PEP 695, which I hope is accepted as the syntax is much
nicer.
Previously the blueprint recorded aspects (before request, after
request etc) would only be added to the app if it was the first
registration of the blueprint instance. However only the record-once
aspects (app-before requests, app-after request) should be added once
on registration of the instance, whereas everything else should be
added on every unique name registration. This ensures that these
trigger under the new name as well as the old.
Following discussions for Flask we've decided to name blueprints based
on how they are registered. This allows for two different blueprints
to have the same self-name as long as they are registered in different
nested positions. This helps users choose better blueprint names.
Firstly `run_sync` was a misleading name as it didn't run anything,
instead I think `async_to_sync` is much clearer as it converts a
coroutine function to a function. (Name stolen from asgiref).
Secondly trying to run the ensure_sync during registration made the
code more complex and brittle, e.g. the _flask_async_wrapper
usage. This was done to pay any setup costs during registration rather
than runtime, however this only saved a iscoroutne check. It allows
the weirdness of the Blueprint and Scaffold ensure_sync methods to be
removed.
Switching to runtime ensure_sync usage provides a method for
extensions to also support async, as now documented.
This allows blueprints to be nested within blueprints via a new
Blueprint.register_blueprint method. This should provide a use case
that has been desired for the past ~10 years.
This works by setting the endpoint name to be the blueprint names,
from parent to child delimeted by "." and then iterating over the
blueprint names in reverse order in the app (from most specific to
most general). This means that the expectation of nesting a blueprint
within a nested blueprint is met.
This allows extensions to override the Flask.ensure_sync method and
have the change apply to blueprints as well. Without this change it is
possible for differing blueprints to have differing ensure_sync
approaches depending on the extension used - which would likely result
in event-loop blocking issues.
This also allows blueprints to have a custom ensure_sync, although
this is a by product rather than an expected use case.
This code originates from the Python 2.4 supporting version of Flask,
with defaultdicts being added in 2.5. Using defaultdict makes the
intentional usage clearer, and slightly simplifies the code.
