Whilst it has been possible to serve via an ASGI server for a while
(using WSGI to ASGI middleware/adapters) it hasn't added much. Now
though it makes sense to recommend the asgiref adapter as it
integrates with the same event loop used for async route handlers
etc...
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 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.
The implementations were moved to Werkzeug, Flask's functions become
wrappers around Werkzeug to pass some Flask-specific values.
cache_timeout is renamed to max_age. SEND_FILE_MAX_AGE_DEFAULT,
app.send_file_max_age_default, and app.get_send_file_max_age defaults
to None. This tells the browser to use conditional requests rather than
a 12 hour cache.
attachment_filename is renamed to download_name, and is always sent if
a name is known.
Deprecate helpers.safe_join in favor of werkzeug.utils.safe_join.
Removed most of the send_file tests, they're tested in Werkzeug.
In the file upload example, renamed the uploaded_file view to
download_file to avoid a common source of confusion.