By default Flask will provide responses to OPTIONS requests that are
automatically generated. These responses list the valid methods in the
response headers. Whilst this is useful, it can be frowned on by
auditors hence an ability to disable it wholesale is useful.
* update pre-commit hook
* upgrade pip with venv
* update description and version
* show url in publish environment
* update versions
* update versions, separate typing job
* use dependabot grouped updates
ignore upload/download-artifact until slsa updates
* use sphinx.ext.extlinks instead of sphinx-issues
* update dev dependencies
* update editorconfig
* update gitignore
* update .readthedocs.yaml
* license is txt, readme is md
* update pyproject.toml
add typed classifier
add pyright config
simplify urls
* tox builds docs in place
* update min test py version
* add tox env to update all dev dependencies
* update issue and pr templates
* rename security docs page to not conflict with org policy file
* simplify matrix
This makes the Flask.url_for self argument positional only (Flask
supports Python 3.8+) thereby restoring the ability to pass self as a
value argument to url_for.
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.
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.
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 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.
