Sortie de Django 6

• La version 6.0 du framework web Django a été publiée, avec prise en charge de Python 3.12+, et un renforcement massif de la sécurité, des templates et des capacités asynchrones
• La Content Security Policy (CSP) est désormais intégrée, ce qui permet de configurer des politiques pour protéger contre les attaques par injection de contenu, dont le XSS
• La fonctionnalité Template Partials permet de définir des parties réutilisables dans les templates, améliorant la modularité du code
• Un framework Background Tasks a été ajouté pour prendre en charge l’exécution de tâches asynchrones en dehors du cycle requête-réponse
• L’adoption d’une API email Python plus récente, la fin du support de MariaDB 10.5 et le changement de la valeur par défaut DEFAULT_AUTO_FIELD permettent d’effectuer des ajustements de compatibilité et de modernisation

---

Compatibilité Python

• Django 6.0 prend en charge Python 3.12, 3.13 et 3.14, avec un support officiel limité aux dernières versions de chaque série
• Django 5.2.x est la dernière version à prendre en charge Python 3.10 et 3.11
• À partir de Django 6.0, il est recommandé aux applications tierces d’arrêter le support des versions antérieures à Django 5.2

Principales nouveautés

Prise en charge de Content Security Policy (CSP)

• La norme CSP est intégrée à Django pour renforcer la protection contre les attaques par injection de contenu comme le XSS
  • Il est possible de définir des politiques via ContentSecurityPolicyMiddleware, le context processor csp() et le paramètre SECURE_CSP
  • Les paramètres basés sur des dictionnaires Python permettent une définition claire et sûre des politiques
• Le mode de surveillance peut être défini via SECURE_CSP_REPORT_ONLY
• Des décorateurs sont proposés pour redéfinir ou désactiver la politique par vue

Template Partials

• Ajout des balises partialdef et partial pour définir et réutiliser des fragments de template
• Le motif template_name#partial_name permet de les référencer directement dans get_template(), render() et {% include %}
• Un guide de migration est fourni pour les utilisateurs du package tiers django-template-partials

Framework de tâches d’arrière-plan

• Ajout d’un framework intégré à Django pour l’exécution de tâches asynchrones
  • L’envoi d’e-mails, le traitement de données, etc. peut être effectué en dehors du cycle requête-réponse HTTP
  • Les tâches sont définies avec le décorateur @task et enregistrées dans la file via enqueue()
• Le backend est spécifié avec TASKS, avec deux backends intégrés par défaut pour le développement et les tests
• Django ne gère que la création et la mise en file des tâches ; l’exécution doit être réalisée par des processus worker externes

Adoption d’une API email Python plus récente

• La logique de traitement des e-mails de Django a été migrée vers la moderne API email de Python (à partir de Python 3.6), email.message.EmailMessage
• Les anciennes classes SafeMIMEText et SafeMIMEMultipart ne sont plus utilisées
• Le type de retour de EmailMessage.message() est désormais une instance EmailMessage de Python

Améliorations détaillées

Admin

• Application du jeu d’icônes Font Awesome Free 6.7.2
• Possibilité de personnaliser le formulaire de changement de mot de passe de l’admin via l’attribut AdminSite.password_change_form
• Des icônes et des styles CSS distincts ont été appliqués à messages.DEBUG et messages.INFO

Auth

• Le nombre d’itérations de hachage PBKDF2 passe de 1 000 000 à 1 200 000

GIS

• L’attribut GEOSGeometry.hasm permet de vérifier la présence de la dimension M
• La fonction Rotate prend en charge la rotation à l’angle indiqué
• Le fournisseur de tuiles de carte peut être personnalisé via l’attribut BaseGeometryWidget.base_layer
• À partir de MariaDB 12.0.1, prise en charge de coveredby, isvalid, GeoHash, IsValid, etc.
• Le JavaScript inline est supprimé lors du rendu des widgets, une modification de template est nécessaire en cas de personnalisation

PostgreSQL

• Les expressions Lexeme sont ajoutées pour renforcer le contrôle de la recherche en texte intégral
• Ajout du paramètre hints aux opérations relatives aux extensions, dont CreateExtension
• Ajout de contrôles système pour les champs, index et contraintes liés à django.contrib.postgres

Staticfiles

• ManifestStaticFilesStorage garantit une cohérence dans le tri des chemins, réduisant les diffs inutiles
• La commande collectstatic affiche par défaut uniquement un résumé, les détails s’affichent à partir de --verbosity 2

Divers

• Ajout de la prise en charge du créole haïtien
• Les commandes startproject et startapp créent automatiquement les répertoires inexistants
• La commande shell importe automatiquement des utilitaires par défaut tels que django.conf.settings
• Prise en charge de la sérialisation de zoneinfo.ZoneInfo dans les migrations
• Ajout de nouvelles fonctions d’agrégation telles que StringAgg, AnyValue
• Prise en charge de la pagination asynchrone via AsyncPaginator et AsyncPage
• Prise en charge de multiples en-têtes Cookie HTTP/2 en environnement ASGI
• Ajout de la variable forloop.length dans les templates, amélioration de la balise querystring
• DiscoverRunner prend en charge les tests parallèles en mode forkserver

Modifications non rétrocompatibles

API du backend de base de données

• BaseDatabaseSchemaEditor et le backend PostgreSQL arrêtent d’utiliser CASCADE lors de la suppression de colonnes
• Changement de noms de méthodes, dont return_insert_columns() → returning_columns()
• Lorsque la prise en charge de UPDATE … RETURNING est activée, il est possible de configurer DatabaseFeatures.can_return_rows_from_update=True

Suppressions de prise en charge

• Fin du support de MariaDB 10.5 (requiert 10.6+)
• Fin du support des versions de Python inférieures à 3.12
  • Versions minimales requises pour les principales bibliothèques : aiosmtpd 1.4.5, bcrypt 4.1.1, Pillow 10.1.0, psycopg 3.1.12, etc.

Email

• Suppression des attributs mixed_subtype, alternative_subtype, encoding
• En raison d’un changement d’implémentation interne, vérification des sous-classes personnalisées d’EmailMessage nécessaire

Changement de la valeur par défaut de DEFAULT_AUTO_FIELD

• La valeur par défaut passe de AutoField à BigAutoField
• Les projets n’ayant pas géré l’avertissement models.W042 depuis Django 3.2 doivent ajouter la configuration

Expressions ORM

• Les paramètres retournés par la méthode as_sql() doivent être de type tuple

Divers

• Ajout systématique d’un saut de ligne lors de la sérialisation JSON
• Version minimale d’asgiref portée à 3.9.1

Fonctionnalités obsolètes prévues

API django.core.mail

• Pour get_connection(), send_mail(), etc., les arguments optionnels doivent être transmis uniquement via des arguments nommés
• Lors de la création d’EmailMessage et d’EmailMultiAlternatives, seuls des arguments nommés sont autorisés après les 4 premiers paramètres

Divers

• Dépréciation de BaseDatabaseCreation.create_test_db(serialize) remplacé par serialize_db_to_string()
• Dépréciation des classes PostgreSQL StringAgg, OrderableAggMixin
• Le protocole par défaut de urlize et urlizetrunc passera à HTTPS dans Django 7.0
• Les paramètres ADMINS et MANAGERS doivent être fournis sous forme de listes de chaînes d’e-mail au lieu de tuples (nom, adresse)
• Dépréciation des classes liées aux e-mails, notamment SafeMIMEText, SafeMIMEMultipart, BadHeaderError

Fonctionnalités supprimées

• Suppression du support des arguments positionnels de BaseConstraint
• Suppression de DjangoDivFormRenderer et Jinja2DivFormRenderer
• Suppression du support du pilote de base de données cx_Oracle
• Le schéma par défaut de forms.URLField passe de "http" à "https"
• Suppression du support des arguments positionnels de Model.save() et Model.asave()
• Suppression de ModelAdmin.log_deletion() et LogEntryManager.log_action()
• Suppression du module django.utils.itercompat
• Suppression des méthodes GeoIP2.coords() et GeoIP2.open()
• Suppression de ForeignObject.get_joining_columns() et des méthodes associées

---

Django 6.0 renforce la robustesse et la scalabilité du framework grâce à la sécurité, au traitement asynchrone et à l’adoption d’une API email moderne, et clarifie la transition vers un environnement Python 3.12+.

[GN⁺]

Avis Hacker News

• Dans une organisation où j’ai travaillé auparavant, il y avait une codebase « moderne » en NodeJS+React, ainsi qu’une application legacy Django basée sur Python 2.7 vieille de près de 15 ans
  Au début, je craignais que l’ancien code soit pénible à gérer, mais c’était en fait tout l’inverse
  L’application Django était agréable à manipuler et le travail de remise en ordre était vraiment amusant. Je pense que ça me manquera le jour où elle sera remplacée par une réécriture en Go/React

  • Je ne vois pas pourquoi la remplacer. Si ce n’est pas cassé, il n’y a pas de raison d’y toucher

• Félicitations à l’équipe Django
  Je maintiens depuis longtemps une application starter Django + Celery + Postgres + Redis + esbuild + Tailwind basée sur Docker Compose, et je l’ai récemment mise à jour pour Django 6.0
  À voir dans le dépôt GitHub
  Je n’ai pas encore activé la configuration CSP par défaut, mais je prévois de l’ajouter après l’avoir examinée plus en détail

  • J’allais le mettre en favori, puis j’ai découvert que je l’avais déjà enregistré en décembre 2023
  • Les dépôts de Nick sont toujours de tout premier ordre. Je les cite souvent moi aussi dans mes propres ressources. Merci de les partager publiquement
  • J’ai utilisé ce template sur un projet il y a quelques années, et il était vraiment excellent
  • Le récent ajout de uv m’a bien montré que le projet est maintenu de manière continue

• La philosophie « batteries included » de Django est parfaitement adaptée à la génération de code par IA
  Le panneau d’administration, la connexion, la réinitialisation du mot de passe et d’autres fonctions de base sont déjà bien en place, ce qui permet à l’IA de créer un site complet avec une petite codebase
  Comme le code est compact et clair, il est aussi facile pour l’IA de l’améliorer de manière itérative

  • L’un des atouts de Django, c’est sa structure de code facile à lire pour les humains
    Au lieu d’énormes composants, on a des modèles et des templates bien définis, ce qui facilite aussi la revue du code généré par l’IA
    De plus, l’admin Django existe comme ground truth indépendante, donc même si le frontend casse, on peut toujours manipuler les données
    Cela dit, je trouve dommage que l’écosystème Python n’ait pas adopté le modèle gevent. La transition vers l’asynchrone aurait alors été bien plus fluide
  • Grâce à la structure INSTALLED_APPS de Django, on peut facilement ajouter ou retirer des fonctionnalités au niveau de l’application
    C’est bien plus intégré que des frameworks faiblement couplés comme Flask ou FastAPI
    Ce genre de différence finit par réduire énormément de petites irritations (papercuts)
  • J’ai utilisé à la fois Django et Rails, et lors de tests avec Claude Code, Rails s’en est beaucoup mieux sorti
    J’ai réécrit une ancienne application .NET : Rails l’a presque parfaitement convertie, alors que Django avait du mal
  • En réalité, Ruby on Rails fournit depuis bien plus longtemps en standard des choses comme le CSP, les background workers et diverses autres fonctionnalités
  • Django est utilisé depuis si longtemps dans l’open source que l’IA dispose d’une abondance de données de code sur lesquelles s’entraîner

• La fonctionnalité template partials de cette release a l’air plutôt intéressante
  Mais l’état des annotations de type (type annotations) reste toujours frustrant
  django-stubs nécessite un plugin mypy, django-types est un fork pour pyright mais la synchronisation ne suit pas bien
  pylance utilise encore son propre fork
  J’espère que la prochaine version inclura au moins officiellement des types de base comme HttpRequest, HttpResponse, View et Model

• Grâce à Django, le développement web a été vraiment plaisant
  Même en passant à d’autres frameworks, je finis toujours par revenir à Django. Je ne l’ai jamais regretté

  • J’ai eu la même expérience avec Ruby on Rails
    Même en essayant d’autres frameworks, je reviens toujours à Rails pour sa commodité
    Cela dit, c’est dommage que Rails n’ait pas d’Admin UI par défaut
  • Si on ne regarde que le backend, Django est excellent, mais du point de vue frontend, il en est encore à l’âge de pierre
    Si vous voulez une vraie expérience full stack, mieux vaut regarder du côté de Laravel ou Rails
  • Honnêtement, je ne vois pas très bien l’attrait de Django
    Je fais du web depuis l’époque de PHP, et Django m’a toujours laissé une impression plutôt moyenne

• Django a été mon premier gros projet freelance, et j’y suis toujours aussi à l’aise
  J’ai tenté plusieurs expérimentations un peu audacieuses, et ça a toujours bien fonctionné. Merci Django

• J’utilise Django presque exclusivement depuis près de 15 ans
  J’ai essayé beaucoup d’autres frameworks, mais aucun ne m’a semblé aussi naturel à prendre en main que Django
  Cette release a ajouté un task framework, mais c’est dommage qu’il n’inclue ni backend ni worker
  J’aimerais presque qu’une version suivante l’intègre sous une forme complète

  • Je me demande si Django a l’intention d’aller jusque-là. Vu la philosophie du framework, il semble accorder de l’importance au maintien des frontières
  • Il ne faut pas que le mieux soit l’ennemi du bien. Django est au fond un framework pour les « perfectionnistes avec des deadlines »

• Le caractère batteries included de Django le rend adapté à n’importe quel projet, quelle qu’en soit la taille
  Bravo à l’équipe et aux contributeurs

• Je me demande comment nous sommes entrés dans l’ère des SPA. Est-ce qu’au départ il s’agissait simplement d’éliminer les spinners de chargement, ou y avait-il une raison plus profonde ?

  • L’une des raisons majeures a été l’arrivée des applications mobiles
    En faisant partager le même backend au web, à iOS et à Android, le modèle SPA s’est naturellement généralisé
    Je continue moi-même à créer des SPA, mais j’aimerais un jour réaliser un gros projet avec Django + htmx
  • À l’époque, je suis passé aux SPA en faisant de la visualisation de données avec Angular
    Le fait d’obtenir un comportement d’application sans rechargement de page était séduisant, mais en pratique il fallait souvent quand même faire un rafraîchissement forcé
    Malgré cela, je trouve élégante la séparation entre les données et leur représentation
  • Le web a d’abord été conçu pour le rendu de documents, mais les utilisateurs voulaient des applications
    Les tentatives pour transformer les documents en applications via JS se sont donc multipliées
  • À l’époque où Internet était lent et où la validation côté backend l’était aussi, on ajoutait du JS pour la validation des formulaires, puis la complexité a augmenté
    On a fini par séparer frontend et backend, avec des contrats d’API et des procédures de validation
    Plus tard, une tendance est apparue pour réintégrer tout cela via les server components, et c’est là où nous en sommes aujourd’hui
    À titre d’exemple, on peut voir un ancien formulaire web à ce lien
  • Les templates comme ceux de Django ou Rails manquaient de sécurité de typage
    C’est pour cela que j’ai fini par préférer les processus de build basés sur TypeScript

• Chaque fois que j’utilise Django, j’éprouve simplement du plaisir. C’est tout