Django 4.1, a new version of the major Python-based web framework, adds capabilities such as asynchronous handlers and an ORM interface but also makes some backward-incompatible changes.
Unveiled August 3, Django 4.1 can be accessed from the Django project website. The new release introduces asynchronous handlers for class-based views; view subclasses now may define async HTTP method handlers, according to release notes.
For asynchronous object-relational mapping,
QuerySet now provides an asynchronous interface for all data access operations. The new interface allows developers to write asynchronous code without needing to write ORM operations in
sync_to_async(). At this stage, underlying database operations remain synchronous.
Django 4.1 supports Python 3.8, Python 3.9, and Python 3.10, but only the latest version of each series. Also in Django 4.1:
exclusionconstraints defined in the
Meta.constraintsoption now are checked during model validation.
<div>-based form templates are available, to aid users who have screen readers and other assistive technology.
CSRF_COOKIE_MASKEDtransitional setting allows developers to specify whether to mask the CSRF (Cross Site Request Forgery) cookie.
SECRET_KEY_FALLBACKSsetting allows for providing a list of values for secret key validation.
- For templates, the HTML
idattribute is no longer required when wrapping the
- For testing, the
DiscoverRunnernow supports running tests in parallel on Windows, macOS, and any other systems where the default
multiprocessingstart method is
A number of backward-incompatible changes were made, including some impacting the database back-end API. Release notes detail specific changes such as
BaseDatabaseFeatures.has_case_insensitive_like being changed from
False to reflect the behaviour of most databases.
Upstream support for PostgreSQL 10 ends in November. Django 4.1 supports PostgreSQL 11 and higher. Additionally, with support for MariaDB 10.2 having ended in May, Django 4.1 supports MariaDB 10.3 and higher.
In another change, in order to unify the behaviour with many-to-many relations for unsaved model instances, a reverse foreign key now raises a ValueError when calling related managers for unsaved objects.