Quart, an ASGI re-implementation of the Flask API has joined the Pallets organization. This means that future development will be under the Pallets governance by the Pallets maintainers.
Our long term aim is to merge Quart and Flask to bring ASGI support directly to Flask. This aim has significant technical obstacles, as outlined in this post or this talk. However, this change clears governance obstacles and brings the Quart and Flask maintainers closer together.
Quart was developed from a desire to use asyncio and the async/await keywords in Flask. Which at the time of Quart's inception was not possible in Flask nor was it possible to add support. Instead Quart was developed as a reimplementation of Flask's API using async/await (learn more from this talk). Later Quart adopted the ASGI standard and is now a compliant ASGI framework.
The Quart API is a superset's of Flask in that it matches Flask's whilst including ASGI specific features such as websockets, for example:
from quart import Quart, render_template, websocket app = Quart(__name__) @app.route("/") async def hello(): return await render_template("index.html") @app.route("/api") async def json(): return {"hello": "world"} @app.websocket("/ws") async def ws(): while True: await websocket.send("hello") await websocket.send_json({"hello": "world"})
You can read more about Quart at quart.palletsprojects.com including a guide to migrating from Flask to Quart.
Quart is an ASGI framework utilising async IO throughout, whereas Flask is a WSGI framework utilising sync IO. It is therefore best to use Quart if you intend to use async IO (i.e. async/await libraries) and Flask if not. Don't worry if you choose the 'wrong' framework though, as Quart supports sync IO and Flask supports async IO, although less efficiently.
The large ecosystem of Flask extensions is a real strength but unfortunately these extensions only work with Flask, and vice versa for Quart extensions. Therefore we plan to enable extensions to support both Flask and Quart in the future.
We expect to keep developing features for both Flask and Quart, in fact a number of features now present in Flask were developed in Quart or from knowledge gained from Quart. This includes typing, async/await support (in Flask), faster routing, and more.
With the closer relationship now possible both Flask and Quart should benefit from new features, shared bug fixes, and more. Please join our discord if you'd like to get involved.
Flask and many of the other Pallets projects benefit from having a diverse ecosystem of user-maintained extensions. However, we recognize that not every extension creator can maintain an extension indefinitely. Last year, the Pallets team started the Pallets Community Organization, aka Pallets-Eco, on GitHub to provide a place where the community can work together to maintain the extensions that we all rely on.
The popular Flask-Caching and Flask-OpenID extensions have already been moved to Pallets-Eco.
In time, we hope that this organization will ensure the stability of the Pallets ecosystem and provide a great point of entry for new contributors.
Although we expect that most extensions we take in will be for Flask, the organization is open to extensions for any of the Pallets projects—Click, Jinja, Werkzeug, etc.
It's important to note, however, that this is not an official extension repository. Extensions in this organization are not guaranteed to be up to date or maintained by the Pallets team. Rather, this is a centralized place for members of the wider community to help maintain these extensions.
The Pallets Community Organization is not currently accepting non-extension projects, such as documentation translations. If you are interested in such projects, join the Pallets Discord and ask about the Flask Community Working Group.
First, reach out on Discord (in the #pallets-eco
channel) to express your interest. Only the current owner of a repository can
transfer it, so please don't inquire on behalf of extensions you don't own. If
there is an abandoned extension that you want to start maintaining, fork it,
work on it, and then ask about joining Pallets-Eco.
Second, review the GitHub docs on transferring a repo. We will work with you to transfer the repo into the Pallets-Eco organization.
Third, you will need to give some of our organization members access to make releases on PyPI.
Keep in mind that transferring your extension to the Pallets Community Organization means you're giving up the final say on how your extension evolves. You will remain as a collaborator on your extension and can continue to contribute, but other members will have input on pull requests and when releases are made. If you prefer to keep your extension completely under your control, then Pallets-Eco is not for you.
Whether you're interested in maintaining one extension in particular or just contributing to the organization overall, we welcome new contributors! This is a great starting point if you've always wanted to contribute to a Pallets project but haven't seen an issue you are ready to tackle—most of the issues in an extension will be smaller in scope and easier to resolve.
All extensions in the Pallets Community Organization follow the same contributing guidelines as the core Pallets projects. Different extensions will come to the organization with different testing coverage and documentation completion. To that end, even if an extension doesn't have open issues, it's likely you could improve its tests and/or docs. After you have reviewed the contributing guidelines, fork the repo, make changes, and open a pull request when you are ready.
Release permissions will be limited to trusted members of the organization
(you could become one in time). If you have questions that don't belong in a
specific extension's issues, ask in #pallets-eco on the Pallets Discord.
The Pallets team is pleased to announce that the next major versions for our six core projects have been released!
This represents two years of work by the Pallets team and community, there are a significant number of changes and exciting new features. Check out the logs for every project to see what's new. Flask depends on the five other libraries, be sure to read them all if you're upgrading Flask.
Install from PyPI with pip. For example, for Flask:
pip install -U Flask
The projects have all dropped support for Python 2 and 3.5, requiring Python 3.6 as the minimum supported version. We plan to follow CPython's supported versions as our supported versions.
Some less common parts of the projects, or parts that we've determined are better served by external implementations, have been deprecated. Previously deprecated code has also been removed. Testing tools such as pytest enable showing deprecation warnings automatically, and can turn them into errors so that you can see early what you may need to change in your project.
While we strive to avoid compatibility issues, there may turn out to be incompatibilities either directly or through other dependencies your project uses, such as Flask extensions. Over the next few weeks, the ecosystem around our projects will continue to update to improve compatibility as necessary. We encourage you to use tools such as pip-compile and Dependabot to pin and control upgrades to your dependencies to avoid unexpected changes.
We are joining the PSF, CPython, and Django, among many other projects, in renaming the default branch of our repositories to "main". GitHub makes this transition easy, see their documentation about how it works for maintainers and users.
If you have a local copy of the repository you'll need to rename its branch to "main".
$ git branch -m master main
$ git fetch origin
$ git branch -u origin/main main
$ git remote set-head origin -a
If you were installing from a GitHub archive URL such as
https://github.com/pallets/flask/archive/refs/heads/master.zip, you'll
need to rename that link to use "main".
These are a few of the great new features and changes to be aware of in the projects. Check out the linked changelogs for the full lists of changes.
async def. Regular sync views continue to work
unchanged. ASGI features such as web sockets are not supported. We
will continue exploring how to add more support for async.@app.post("/login") is a shortcut for
@app.route("/login", methods=["POST"]).Config.from_file function to load config from any file
format.flask shell command enables tab completion like the regular
python shell does.multipart/form-data has been optimized and shows a 15x
speedup, especially for large file uploads.ContextVar to allow working across async
coroutines instead of only threads.Request and Response
classes are becoming sans-io. This will allow us to better support
sync and async use cases in the future.Response class that includes a
reference to the original request, environ, and any redirects that
were followed.datetime objects returned by some headers and functions are
timezone-aware.ws:// and wss:// schemes and will
route appropriately. While there is no direct support for
websockets, this allows other projects to use Werkzeug's routing.send_file and
send_from_directory to Werkzeug.0.0.0.0 and warns about
not running in production.required.if blocks and ternary statements
can be undefined at runtime. Tests have been added to check if a
filter or test is available, to allow optionally using them.pgettext and npgettext.NativeEnvironment supports enable_async mode.style supports 256 and RGB color codes supported by modern
terminals, as well as the strikethrough, italic, and overline
styles.multiple=True or nargs don't require setting a
default, and properly validate the format of a default if it's
given.*.txt and ~/config.json, since the Windows terminal does not
support this automatically.gettext.datetime objects are timezone-aware.Follow our blog RSS feed or our Twitter @PalletsTeam to get future updates. We also have an official Discord server https://discord.gg/pallets for chatting, asking questions, and contributing to the projects.
If you're interested in contributing, each project has a guide showing how to get started with a development environment and the tools we use. Check out the issue trackers for each project for what to work on. Use the Watch feature on GitHub see new issues, PRs, and the discussions we have around them.
The Pallets organization accepts donations as part of the non-profit Python Software Foundation (PSF). Donations through the PSF support our efforts to maintain the projects and grow the community.
The Pallets team and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open source dependencies you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact dependencies you use.
We've made amazing progress, both by working through the backlog of issues and PRs, as well as growing the team and community. We have so many more exciting things in store. Look for more updates soon on community projects such as documentation translations and FlaskCon Online 2021! Thank you so much for using, supporting, and contributing to the Pallets projects!
The Pallets team is pleased to announce that release candidates are now available for the next major version of each project.
Check out the changelogs for every project to see what's new:
Please help us prepare for the final release by testing the prerelease
versions and reporting any issues you have. To upgrade to pre-releases
with pip, use the --pre flag, e.g.:
pip install -U --pre Flask
These new major versions all drop support for Python 2 and 3.5, requiring Python 3.6 as the minimum supported version.
These are a few highlights, see the changelogs linked above for the full release details. More detailed posts about each project's highlights will be made with the final releases.
async/await support.@app.post()
as a shortcut for @app.route(methods=["POST"]).send_file and send_from_directory helpers.Response object.The Pallets team is aiming to release on or before PyCon 2021, i.e. a target release date of the 11th of May 2021.
The Pallets team is pleased to release Click 7.1.
Read the full changelog to understand what may affect your code when upgrading.
This also fixes a packaging issue from 7.0 where the project name in the package metadata was changed to "Click" with an upper case "C". This has been reverted, the name is now correctly reported in all lower case, "click".
As outlined in Ending Python 2 Support, 7.1.x will be the last version to support Python 2.7 and 3.5. The next version will be 8.0 and will support Python 3.6 and newer.
Install from PyPI with pip:
pip install -U click
The Pallets organization accepts donations as part of the non-profit Python Software Foundation (PSF). Donations through the PSF support our efforts to maintain the projects and grow the community.
The Pallets team is pleased to release Werkzeug 1.0. Werkzeug is the low-level WSGI and HTTP toolkit that powers Flask. It's been almost 13 years since the first commit, and this milestone for the project brings many fixes and changes. Read the full changelog to understand what may affect your code when upgrading.
werkzeug module
in favor of direct imports. If you haven't already, use
version 0.16 first to see
deprecation warnings while upgrading.samesite='None' option. Cookies are parsed
as a MultiDict instead of overwriting repeated keys.Accept header preserves order for tags with equal quality and
considers options on each value. The Accept-Language header can
match the primary tag if the specific value is not present.Request and Response.websocket, in which case it will
only match for wss:// requests. This allows async web frameworks
to use Werkzeug for routing.As outlined in Ending Python 2 Support, 1.0.x will be the last version to support Python 2.7 and 3.5. The next version will be 2.0 and will support Python 3.6 and newer.
Install from PyPI with pip:
pip install -U Werkzeug
The Pallets organization accepts donations as part of the non-profit Python Software Foundation (PSF). Donations through the PSF support our efforts to maintain the projects and grow the community.
The Pallets team and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open source dependencies you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact dependencies you use.
The Pallets team is pleased to release Jinja 2.11.0. Read the changelog for the full list of changes. Some of the bigger changes include:
jinja2.ext.debug extension adds a {% debug %} tag to
quickly dump the current template context.ChainableUndefined type allows silently ignoring attribute
access on undefined variables.loop.length and loop.nextitem work
better in both sync and async environments.As outlined in Ending Python 2 Support, 2.11.x will be the last version to support Python 2.7 and 3.5. The next version will be 3.0 and will support Python 3.6 and newer.
The package name will remain "Jinja2" and imports will remain jinja2.
"Jinja2 3.0" looks a little weird, but given the years of community
momentum behind the name, we concluded it was less disruptive to keep it
as-is.
Install from PyPI with pip:
pip install -U Jinja2
The Pallets organization accepts donations as part of the non-profit Python Software Foundation (PSF). Donations through the PSF support our efforts to maintain the projects and grow the community.
The Pallets team and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open source dependencies you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact dependencies you use.
Upstream support for Python 2.7 is ending on January 1, 2020. Pallets is joining the community of open source projects ending support for Python 2 at that time. Our statement and support plan are based on PyTest's announcement.
We will be dropping support for Python 2.7 as well as Python 3.5 and below, as their support windows have ended or will end around the same time. Future releases of each Pallets project will only support Python versions still supported upstream, which can be found in the Python Developer's Guide.
The last version branch of each core project to support Python 2.7 and Python 3.5 are:
Each project will receive a major version bump to indicate support for only 3.6+:
Thanks to the python_requires package metadata, Python 2.7 and
3.5 users with a modern pip version will install the last supported
version automatically even if later versions are available.
The team will no longer backport patches for unsupported versions, but the branches will continue to exist. The team will be happy to accept patches contributed by the community for any severe security and usability issues until mid-2020.
We made this decision based on multiple factors. Foremost is ease of community contribution and maintainer availability. As time goes on, fewer contributors have used or are familiar with the differences between Python 2 and 3. Contributors and maintainers must keep track of an ever growing list of obscure compatibility issues and workarounds, and cannot use many modern features.
Over the last two years, we've talked to many developers and teams at conferences and meetups and heard overwhelming support for the move to Python 3. This is backed up by data collected from our community in a survey we ran during January 2019, with 92% of respondents already using or actively upgrading to Python 3. The PSF developer survey and PyPI statistics report similar majorities and show adoption continuing to increase.
Thank you to everyone in the community for your support, and to everyone who has made this transition a reality. We look forward to continuing to develop the Pallets projects with you!
Werkzeug 0.16.0 has been released. The only change is that most of the
top-level attributes in the werkzeug module are now deprecated, and
will be removed in 1.0.0.
For example, instead of import werkzeug; werkzeug.url_quote, do
from werkzeug.urls import url_quote. If you are using these imports in
your project, a deprecation warning will show the correct import to use.
werkzeug.exceptions and werkzeug.routing should also be imported
instead of accessed, but for technical reasons can’t show a warning.
These imports were supported by patching the werkzeug module to
support lazy imports, but the implementation added complexity, and there
was no clear design reason why some things were available and some
weren't. It also masked some circular dependency issues. IDEs like
PyCharm didn't know those lazy imports existed and were already
correctly using the full imports.
Werkzeug 0.15.5 has been released, containing bug and security fixes. The changelog lists the changes in detail, which include:
SharedDataMiddleware safely handles drive names in paths on Windows.Exec format error in many common
situations.SharedDataMiddleware on WindowsPrior to 0.15.5, it was possible for a third party to potentially access
arbitrary files when the application used SharedDataMiddleware on
Windows. This issue was assigned CVE-2019-14322.
Due to the way Python's os.path.join() function works on Windows, a
path segment with a drive name will change the drive of the final path.
This was previously addressed in the safe_join() function in
Werkzeug 0.12.2, but SharedDataMiddleware used a separate
implementation and so was not secured by the previous fix.
SharedDataMiddlware now uses safe_join() when fetching requested
files. Projects using SharedDataMiddleware on Windows should update
as soon as possible to receive the fix.
Thank you to Emre Övünç and Olivier Dony for responsibly reporting the issue. If you think you have discovered a security issue in Werkzeug or another of the Pallets projects, please email [email protected] with details.
Install from PyPI with pip:
pip install -U Werkzeug