It is better to encourage users to utilise the app ensure_sync method
(or the newely added async_to_sync method) so that any extensions that
alter these methods take affect throughout the users code.
With the helper method users code fix parts of their code to the
asgiref async_to_sync ignoring any extension changes.
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.
Wrapped functions are not comparable, see
https://bugs.python.org/issue3564, therefore a marker is used to note
when the function has been sync wrapped to allow comparison with the
wrapped function instead.
This ensures that multiple route decorators work without raising
exceptions i.e.,
@app.route("/")
@app.route("/a")
async def index():
...
works.
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.
Werkzeug offers a ContextVar replacement for Python < 3.7, however it
doesn't work across asyncio tasks, hence it makes sense to error out
rather than find there are odd bugs.
Note the docs build requires the latest (dev) Werkzeug due to this
change (to import ContextVar from werkzeug.local).
This allows for async functions to be passed to the Flask class
instance, for example as a view function,
@app.route("/")
async def index():
return "Async hello"
this comes with a cost though of poorer performance than using the
sync equivalent.
asgiref is the standard way to run async code within a sync context,
and is used in Django making it a safe and sane choice for this.
David Lord
pre-commit-ci[bot]
Miguel Grinberg
pgjones