Split the App and Blueprint into Sansio and IO parts #5127
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pgjones
commented
Jun 7, 2023
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
davidism
reviewed
Aug 19, 2023
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.