Discussion :

[Alex]

Le framework web libre et open source basé sur Python Django 6.0 beta 1 est désormais disponible, représentant la deuxième étape du cycle de publication de la version 6.0

Django 6.0 beta 1 est désormais disponible. Il représente la deuxième étape du cycle de publication de la version 6.0 et permet de tester les changements apportés à Django 6.0. Django 6.0 rassemble une mosaïque d'outils modernes et de conceptions bien pensées, que vous pouvez découvrir dans les notes de publication de la version 6.0 en cours de développement. Seuls les bugs dans les nouvelles fonctionnalités et les régressions par rapport aux versions précédentes de Django seront corrigés d'ici la version finale 6.0.

Django est un framework web gratuit et open source basé sur Python qui s'exécute sur un serveur web. L'objectif principal de Django est de faciliter la création de sites web complexes basés sur des bases de données. Le framework met l'accent sur la réutilisabilité et la « connectivité » des composants, la réduction du code, le faible couplage, le développement rapide et le principe « ne te répète pas ». Python est utilisé partout, même pour les paramètres, les fichiers et les modèles de données. Django fournit également une interface administrative optionnelle de création, lecture, mise à jour et suppression qui est générée dynamiquement par introspection et configurée via des modèles d'administration.

Django 6.0 beta 1 est désormais disponible. Il représente la deuxième étape du cycle de publication de la version 6.0 et permet de tester les changements apportés à Django 6.0. Django 6.0 rassemble une mosaïque d'outils modernes et de conceptions bien pensées, que vous pouvez découvrir dans les notes de publication de la version 6.0 en cours de développement. Seuls les bugs dans les nouvelles fonctionnalités et les régressions par rapport aux versions précédentes de Django seront corrigés d'ici la version finale 6.0. Les traductions seront mises à jour après le « string freeze », qui a lieu lorsque la version candidate est publiée.

Le calendrier de publication actuel prévoit une version candidate dans environ un mois, la version finale étant prévue environ deux semaines plus tard, le 3 décembre. Des tests précoces et fréquents de la part de la communauté permettront de réduire au minimum le nombre de bogues dans la version. Les mises à jour du calendrier de publication sont disponibles sur le forum Django. Comme pour tous les paquets alpha et bêta, cette version n'est pas destinée à une utilisation en production.

Voici les nouveautés de Django 6.0 :

Prise en charge de la politique de sécurité du contenu

La prise en charge intégrée de la norme CSP (Content Security Policy) est désormais disponible, ce qui facilite la protection des applications web contre les attaques par injection de contenu telles que le cross-site scripting (XSS). La CSP permet de déclarer des sources de contenu fiables en donnant aux navigateurs des règles strictes sur les scripts, styles, images ou autres ressources qui peuvent être chargés.

Les politiques CSP peuvent désormais être appliquées ou surveillées directement à l'aide d'outils intégrés : les en-têtes sont ajoutés via ContentSecurityPolicyMiddleware, les nonces sont pris en charge par le processeur de contexte csp(), et les politiques sont configurées à l'aide des paramètres SECURE_CSP et SECURE_CSP_REPORT_ONLY.

Ces paramètres acceptent les dictionnaires Python et prennent en charge les constantes fournies par Django pour plus de clarté et de sécurité. Par exemple :

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
from django.utils.csp import CSP
 
SECURE_CSP = {
    "default-src": [CSP.SELF],
    "script-src": [CSP.SELF, CSP.NONCE],
    "img-src": [CSP.SELF, "https:"],
}

L'en-tête Content-Security-Policy résultant serait défini comme suit :

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

default-src 'self'; script-src 'self' 'nonce-SECRET'; img-src 'self' https:

Modèles partiels

Le langage de modèle Django prend désormais en charge les modèles partiels, ce qui facilite l'encapsulation et la réutilisation de petits fragments nommés dans un fichier de modèle. Les nouvelles balises {% partialdef %} et {% partial %} définissent respectivement un modèle partiel et le rendent.

Les fragments peuvent également être référencés à l'aide de la syntaxe template_name#partial_name avec get_template(), render(), {% include %} et d'autres outils de chargement de modèles, ce qui permet d'obtenir des modèles plus modulaires et plus faciles à maintenir sans avoir à diviser les composants en fichiers séparés.


Tâches en arrière-plan

Django inclut désormais un framework Tasks intégré pour exécuter du code en dehors du cycle requête-réponse HTTP. Cela permet de décharger certaines tâches, telles que l'envoi d'e-mails ou le traitement de données, vers des workers en arrière-plan.

Les tâches sont définies à l'aide du décorateur task() :

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
from django.core.mail import send_mail
from django.tasks import task
 
 
@task
def email_users(emails, subject, message):
    return send_mail(subject, message, None, emails)

Une fois définies, les tâches peuvent être mises en file d'attente via un backend configuré :

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
email_users.enqueue(
    emails=["user@example.com"],
    subject="You have a message",
    message="Hello there!",
)

Les backends sont configurés via le paramètre TASKS. Les deux backends intégrés inclus dans cette version sont principalement destinés au développement et aux tests.

Django gère la création et la mise en file d’attente des tâches, mais ne fournit pas de mécanisme de travail pour exécuter les tâches. L’exécution doit être gérée par une infrastructure externe, telle qu’un processus ou un service distinct.


Adoption de l’API e-mail moderne de Python

La gestion des e-mails dans Django utilise désormais l'API moderne de Python pour les e-mails, introduite dans Python 3.6. Cette API, centrée autour de la classe email.message.EmailMessage, offre une interface plus claire et compatible avec Unicode pour la composition et l'envoi d'e-mails. Elle remplace l'ancienne API héritée (Compat32) de Python, qui reposait sur des classes MIME de niveau inférieur (provenant de email.mime) et nécessitait une gestion plus manuelle de la structure et de l'encodage des messages.

Il est à noter que le type de retour de la méthode EmailMessage.message() est désormais une instance de email.message.EmailMessage de Python. Celle-ci prend en charge la même API que les types de retour SafeMIMEText et SafeMIMEMultipart précédents, mais n'est pas une instance de ces classes désormais obsolètes.

Source : Django

Et vous ?

Pensez-vous que cette annonce est crédible ou pertinente ?
Quel est votre avis sur cette version ?

Voir aussi :

La version 5.0 de Django est disponible, et introduit une fonctionnalité qui permet d'utiliser les propriétés par défaut des bases de données, ainsi qu'une construction simplifiée des formulaires

Python 3.14 est disponible : cette version est environ 27 % plus rapide que Python 3.13 et introduit un compilateur JIT expérimental, le mode Free-Threaded, les chaînes t-string et diverses améliorations

Langages les plus utilisés en 2025 : Python règne en maître, SQL revient en force, JavaScript perd du terrain, selon IEEE. L'impact du vibe coding IA commencerait-il à se faire ressentir sur les index ?

[Sve@r]

Bonjour

Pensez-vous que cette annonce est crédible ou pertinente ?

Oui

Quel est votre avis sur cette version ?

Moi je me suis mis à Django il y a peu de temps donc mon avis aura la faiblesse de mon inexpérience mais j'aime bien. J'aime surtout cette histoire de "task" permettant de reporter des tâches annexes sur un module background.

[Alex]

Django 6, le framework web gratuit et open source basé sur Python, est disponible, avec la prise en charge intégrée de la norme CSP ainsi qu'un framework de tâches intégré pour les tâches en arrière-plan

L'équipe Django a annoncé la sortie de la version finale de Django 6.0. Parmi les améliorations de cette version, on peut noter la prise en charge intégrée de la norme CSP (Content Security Policy), la prise en charge des modèles partiels, et un framework de tâches intégré pour exécuter du code en dehors du cycle requête-réponse HTTP. La gestion des e-mails dans Django utilise désormais l'API moderne de Python pour les e-mails, introduite dans Python 3.6.

Django est un framework web gratuit et open source basé sur Python qui s'exécute sur un serveur web. L'objectif principal de Django est de faciliter la création de sites web complexes basés sur des bases de données. Le framework met l'accent sur la réutilisabilité et la « connectivité » des composants, la réduction du code, le faible couplage, le développement rapide et le principe « ne te répète pas ». Python est utilisé partout, même pour les paramètres, les fichiers et les modèles de données. Django fournit également une interface administrative optionnelle de création, lecture, mise à jour et suppression qui est générée dynamiquement par introspection et configurée via des modèles d'administration.

En octobre, Django 6.0 beta 1 était disponible. Il représente la deuxième étape du cycle de publication de la version 6.0 et permet de tester les changements apportés à Django 6.0. Django 6.0 rassemble une mosaïque d'outils modernes et de conceptions bien pensées, que vous pouvez découvrir dans les notes de publication de la version 6.0 en cours de développement. Selon l'équipe Django, seuls les bugs dans les nouvelles fonctionnalités et les régressions par rapport aux versions précédentes de Django seront corrigés d'ici la version finale 6.0.

Récemment, l'équipe Django a annoncé la sortie de la version finale de Django 6.0. Parmi les améliorations de cette version, on peut noter les modèles partiels : modularisez les modèles à l'aide de petits fragments nommés pour un code plus propre et plus facile à maintenir, les tâches en arrière-plan : exécutez du code en dehors du cycle de requêtes-réponses HTTP grâce à un framework de tâches intégré et flexible, la politique de sécurité du contenu (CSP) : configurez et appliquez facilement des politiques de sécurité au niveau du navigateur pour vous protéger contre l'injection de contenu, ainsi que les API de messagerie modernisée : rédigez et envoyez des e-mails avec la classe EmailMessage de Python pour une interface plus claire et compatible avec Unicode.

Avec la sortie de Django 6.0, Django 5.2 a atteint la fin de son support principal. La dernière version mineure de correction de bogues, 5.2.9, a été publiée hier. Django 5.2 bénéficiera de correctifs de sécurité et de perte de données jusqu'en avril 2028. Tous les utilisateurs sont encouragés à effectuer la mise à niveau avant cette date afin de continuer à bénéficier des correctifs de sécurité. Django 5.1 a atteint la fin de son support étendu. La dernière version de sécurité, 5.1.15, a été publiée le 2 décembre 2025. Tous les utilisateurs de Django 5.1 sont encouragés à passer à une version prise en charge de Django.

Compatibilité Python

Django 6.0 prend en charge Python 3.12, 3.13 et 3.14. La série Django 5.2.x est la dernière à prendre en charge Python 3.10 et 3.11.

Prise en charge des bibliothèques tierces pour les anciennes versions de Django

Suite à la sortie de Django 6.0, il est suggéré aux auteurs d'applications tierces d'abandonner la prise en charge de toutes les versions de Django antérieures à la 5.2. À ce moment-là, vous devriez pouvoir exécuter les tests de votre paquet à l'aide de python -Wd afin que les avertissements de dépréciation apparaissent. Après avoir corrigé les avertissements de dépréciation, votre application devrait être compatible avec Django 6.0.

Prise en charge de la politique de sécurité du contenu

La prise en charge intégrée de la norme CSP (Content Security Policy) est désormais disponible, ce qui facilite la protection des applications web contre les attaques par injection de contenu telles que le cross-site scripting (XSS). La CSP permet de déclarer des sources de contenu fiables en donnant aux navigateurs des règles strictes sur les scripts, styles, images ou autres ressources qui peuvent être chargés.

Les politiques CSP peuvent désormais être appliquées ou surveillées directement à l'aide d'outils intégrés : les en-têtes sont ajoutés via ContentSecurityPolicyMiddleware, les nonces sont pris en charge par le processeur de contexte csp(), et les politiques sont configurées à l'aide des paramètres SECURE_CSP et SECURE_CSP_REPORT_ONLY.

Ces paramètres acceptent les dictionnaires Python et prennent en charge les constantes fournies par Django pour plus de clarté et de sécurité. Par exemple :

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
from django.utils.csp import CSP
 
SECURE_CSP = {
    "default-src": [CSP.SELF],
    "script-src": [CSP.SELF, CSP.NONCE],
    "img-src": [CSP.SELF, "https:"],
}

L'en-tête Content-Security-Policy résultant serait défini comme suit :

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

default-src 'self'; script-src 'self' 'nonce-SECRET'; img-src 'self' https:

Modèles partiels

Le langage de modèle Django prend désormais en charge les modèles partiels, ce qui facilite l'encapsulation et la réutilisation de petits fragments nommés dans un fichier de modèle. Les nouvelles balises {% partialdef %} et {% partial %} définissent respectivement un modèle partiel et le rendent.

Les fragments peuvent également être référencés à l'aide de la syntaxe template_name#partial_name avec get_template(), render(), {% include %} et d'autres outils de chargement de modèles, ce qui permet d'obtenir des modèles plus modulaires et plus faciles à maintenir sans avoir à diviser les composants en fichiers séparés.

Tâches en arrière-plan

Django inclut désormais un framework de tâches intégré pour exécuter du code en dehors du cycle requête-réponse HTTP. Cela permet de décharger certaines tâches, telles que l'envoi d'e-mails ou le traitement de données, vers des travailleurs en arrière-plan.

Le framework fournit la définition des tâches, la validation, la mise en file d'attente et la gestion des résultats. Django garantit un comportement cohérent pour la création et la gestion des tâches, tandis que la responsabilité de leur exécution continue d'incomber aux processus de travail externes.

Les tâches sont définies à l'aide du décorateur task() :

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
from django.core.mail import send_mail
from django.tasks import task
 
 
@task
def email_users(emails, subject, message):
    return send_mail(subject, message, None, emails)

Une fois définies, les tâches peuvent être mises en file d'attente via un backend configuré :

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
email_users.enqueue(
    emails=["user@example.com"],
    subject="You have a message",
    message="Hello there!",
)

Les backends sont configurés via le paramètre TASKS. Les deux backends intégrés inclus dans cette version sont principalement destinés au développement et aux tests.

Django gère la création et la mise en file d'attente des tâches, mais ne fournit pas de mécanisme de travail pour exécuter les tâches. L'exécution doit être gérée par une infrastructure externe, telle qu'un processus ou un service distinct.

Adoption de l’API moderne de Python pour les e-mails

La gestion des e-mails dans Django utilise désormais l'API moderne de Python pour les e-mails, introduite dans Python 3.6. Cette API, centrée autour de la classe email.message.EmailMessage, offre une interface plus claire et compatible avec Unicode pour la composition et l'envoi d'e-mails. Elle remplace l'ancienne API héritée (Compat32) de Python, qui reposait sur des classes MIME de niveau inférieur (provenant de email.mime) et nécessitait une gestion plus manuelle de la structure et de l'encodage des messages.

Il est à noter que le type de retour de la méthode EmailMessage.message() est désormais une instance de email.message.EmailMessage de Python. Celle-ci prend en charge la même API que les types de retour SafeMIMEText et SafeMIMEMultipart précédents, mais n'est pas une instance de ces classes désormais obsolètes.

Source : Obtenir Django 6.0

Et vous ?

Pensez-vous que cette mise à jour est crédible ou pertinente ?
Quel est votre avis sur cette version ?

Voir aussi :

La version 5.0 de Django est disponible, et introduit une fonctionnalité qui permet d'utiliser les propriétés par défaut des bases de données, ainsi qu'une construction simplifiée des formulaires

Python 3.14 est disponible : cette version est environ 27 % plus rapide que Python 3.13 et introduit un compilateur JIT expérimental, le mode Free-Threaded, les chaînes t-string et diverses améliorations

[smarties]

Ca va dans la philosophie de Django "all battery included". J'espère que les ressources sont bien gérées par contre à ce niveau.

Cependant, aujourd'hui, je ne partirais plus sur des nouveaux projets django. Je préfère les framework que je compose avec différentes briques (FastAPI ou Flask ou autre pour le web, Alembic pour les migrations, SQLAlchemy, pytest plutôt que unittest de django). Rien que pour la gestion des utilisateurs, si on a besoun d'utilisateurs enrichis, de groupes enrichis, de gérer des tenants, des token API on a un projet qui quasiment 10 tables (celles de Django et DRF incluses) car nous avons besoin d'étendre les données.
J'ai aussi django-stubs pour le typing mais VSCode a quand même des soucis de détections que j'ai beaucoup moins sur les autres framework.
L'ORM est moins puissant qu'SQLAlchemy a mon goût.
Un jour j'ai utilisé la bibliothèque ConfZ et depuis je trouve la gestion de configuration de django beaucoup moins bien.

[Bayard]

smarties : très intéressant.
Pouvez-vous nous en dire plus, notamment sur confZ ?
Par ailleurs, avec django, en faisant une classe modèle, je gagne un page d'admin web et une classe utilisable pour l'API. Est-ce toujours possible avec votre alternative ?