Split the App and Blueprint into Sansio and IO parts #5127
Conversation
pgjones
changed the title
pgjones
force-pushed
the
sansio
branch
2 times, most recently
from
194b16d to
c247d3a
Compare
pgjones
force-pushed
the
sansio
branch
3 times, most recently
from
6938ade to
751777f
Compare
|
Should be able to rebase to fix the pre-commit failure. |
|
Remind me what the issue with sharing |
This is preperation for refactoring the files so that there are sansio and flask specific versions. This structure follows the Werkzeug structure/pattern.
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 allows a Blueprint implementation that has additional funcs, such as Quart with its before_websocket_funcs (as example), to extend the merge method to also merge these functions.
This is useful as there is contextual information that could be loaded via IO e.g. information from a database. This also matches Quart and hence makes the shared signature easier to manage.
Whilst not strictly true for Flask, it is true for Flask and Quart and hence makes it much easier for Quart to extend Flask classes. The alternatives are generic usage in the sansio codebase or mixed usage within Flask. I think this is a good compromise.
It may also be awaitable, as invocations are wrapped in ensure_sync.
This should hopefully explain what it is used for and why certain code cannot be present in it.
Partially, as the wrong type does make things difficult for users. Which on a related typing note, I think the next step for this (ideally post merge) is to make the sansio parts Generic in the response return type, to allow for Quart to use async iterators (which is too hard I think in Flask to achieve) and for Flask's typing to again be narrowed. The main issue is I'd like to keep https://github.com/pgjones/quart-flask-patch working, which will require flask's current_app and request to be different instances to quart's. |
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. (We may be able to change this in the future, but I think we should let this change settle first).
Checklist:
CHANGES.rstsummarizing the change and linking to the issue... versionchanged::entries in any relevant code docs.pre-commithooks and fix any issues.pytestandtox, no tests failed.