Five fantastic additions to Django 5

The new Django will have easier form fields, more support for async, and simpler methods for handling form selections.

The fifth major release of Django, the Python web framework that comes with all the batteries included, is almost here. Here’s a summary of the top five new features in Django 5, which you should utilize in your new and current Django applications.

Top 5 Django 5 new features

1. Form fields render more easily.
2. Model fields for generated columns and calculations
3. Writing field selections is simpler.
4. More decorators for async views
5. Managing exceptions for async disconnects

1. It is easier to present form fields
Django form fields consist of the field itself, an error label, a descriptive label, and help text. It can be time-consuming to arrange these fields by hand if your form has several of them.

Django 5 provides a new field group technique for form fields to address that. The .as_field_group method, when used in a template, automatically renders each element in the field group in accordance with a customizable template.

With field groups, you can render all this:

{{ form.username.label_tag }}
{% if form.username.help_text %}
<div class="helptext" id="{{ form.username.auto_id }}_helptext">
    {{ form.username.help_text|safe }}
</div>
{% endif %}
{{ form.username.errors }}
{{ form.username }}

… as just this:

{{ form.name.as_field_group }}

Once more, you have customization options for the presentation. You can change the application-wide default design for field groups or adjust it per-field or even per-request.

2. Calculation model fields and produced columns
Databases with computed columns enable you to specify the column’s value as the result of a formula that is calculated internally before being sent to the client.

You can now specify a database-computed default value for fields in models by using the database default argument, which was added in Django 5. For example, a DateTimeField’s default value may be Now().

Keep in mind that the only value that can be assigned to db_default is the result of combining literals with approved database operations.

GeneratedField, a new field type whose value is always produced from the values of other fields, is another useful Django 5.0 innovation along these lines. A “stored” field records the results when the row is written or modified, but a “virtual” field computes the results only when the row is read.

Keep in mind that the fields that GeneratedFields can use as inputs are limited to those in the same model. Additionally, only genuine fields may be used as sources; created fields are not permitted.

3. It is simpler to write field selections
Earlier versions of Django required you to provide an awkward configuration of 2-tuples or Enumeration subclasses in order to list the options accessible to Field.choices and ChoiceField.choices objects:

HQ_LOCATIONS = [
    ("United States", [("nyc", "New York"), ("la", "Los Angeles")]),
    ("Japan", [("tokyo", "Tokyo"), ("osaka", "Osaka")]),
    ("virtual", "Anywhere"),
]

With Django 5, you can use a much more succinct declaration using dictionary mappings:

HQ_LOCATIONS = {
    "United States": {"nyc": "New York", "la": "Los Angeles"},
    "Japan": {"tokyo": "Tokyo", "osaka": "Osaka"},
    "virtual": "Anywhere",
}

This facilitates the encoding of options as literals and also somewhat simplifies their programmatic generation.

4. A lot more decorators of async views
In 3.0, Django introduced its initial support for Python’s asynchronous techniques; however, not all Django features were initially supported in an async manner. It has been implemented gradually; in version 4.0, async view support was provided, and in a later release, support for the ORM.

Many decorators didn’t allow wrapping async views in the past since Django has been gradually introducing support for async views. Version 5 brings about this feature, allowing many more decorators to cover async views. The ones that protect views against CSRF (cross-site request forgery) are among the most beneficial.

5. Handling async disconnect exceptions
A persistent connection may be terminated by Django before it can respond when using async connections. Previously, when an async connection was canceled, there was no built-in method to manage cleanup. Asyncio.CancelledError is the proper exception raised by Django 5, which you can catch as needed.