Le framework web libre et open source basé sur Python Django 6.0 beta 1 est disponible
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:
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:
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:
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:
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 ?
:fleche: Pensez-vous que cette annonce est crédible ou pertinente ?
:fleche: Quel est votre avis sur cette version ?
Voir aussi :
:fleche: 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
:fleche: 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
:fleche: 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 ?
