La version 3.2 du framework Django est disponible, avec la découverte automatique d'AppConfig,

Elle apporte de nouveaux décorateurs pour le module d'administration

L'équipe de développement de Django a annoncé le 6 avril la sortie de la version 3.2 de Django. Cette version a été désignée comme une version de support à long terme (LTS), ce qui signifie que les corrections de sécurité et de perte de données seront appliquées pour au moins les trois prochaines années. Elle recevra également des correctifs pour les bogues de plantage, les bogues de fonctionnalité majeurs dans les fonctionnalités nouvellement introduites et les régressions à partir des anciennes versions de Django pour les huit prochains mois jusqu'en décembre 2021. Avec la sortie de Django 3.2, Django 3.1 ne recevra plus de support général.

La dernière version de correction de bogues mineurs, 3.1.8, a été publiée le 6 avril. Django 3.1 recevra des corrections de sécurité et de perte de données jusqu'en décembre 2021. Il est recommandé aux utilisateurs d’effectuer une mise à niveau avant cette date afin de continuer à recevoir les corrections pour des modules de sécurité. Django fournit une interface administrative facultative de création, de lecture, de mise à jour et de suppression qui est générée dynamiquement par introspection et configurée via des modèles d'administration.


Notons que Django est un framework web libre et open source basé sur Python qui suit le modèle architectural modèle-vues (MTV). Il est maintenu par la Django Software Foundation (DSF), une organisation indépendante américaine à but non lucratif. L'objectif principal de Django est de faciliter la création de sites Web complexes, axés sur les bases de données. Python est utilisé partout, même pour les paramètres, les fichiers et les modèles de données. Parmi les sites bien connus qui utilisent Django figurent PBS, Instagram, Mozilla, The Washington Times, Disqus, Bitbucket, et Nextdoor. Voici, ci-dessous, les nouveautés apportées par la version 3.2 de Django.

Découverte automatique d'AppConfig

La plupart des applications définissent une sous-classe AppConfig dans un sous-module apps.py. Beaucoup définissent une variable default_app_config pointant vers cette classe dans leur __init__.py.
Lorsque le sous-module apps.py existe et définit une seule sous-classe AppConfig, Django utilise maintenant cette configuration automatiquement, default_app_config n’est donc plus nécessaire.

default_app_config permet de déclarer uniquement le chemin de l'application dans INSTALLED_APPS (par exemple, django.contrib.admin) plutôt que le chemin de l'app config (par exemple, django.contrib.admin.apps.AdminConfig). Il a été introduit par souci de rétrocompatibilité avec le premier style, avec l'intention de faire basculer l'écosystème vers le second, mais ce basculement n'a pas eu lieu. Avec la découverte automatique d'AppConfig, default_app_config n'est plus nécessaire. En conséquence, il est déprécié.

Rappelons que pour configurer une application, on crée un module apps.py dans l'application, puis on définit une sous-classe d'AppConfig.

Lorsque INSTALLED_APPS contient le chemin en pointillés vers un module d'application, par défaut, si Django trouve exactement une sous-classe d'AppConfig dans le sous-module apps.py, il utilise cette configuration pour l'application. Ce comportement peut être désactivé en définissant AppConfig.default sur False.

Si le module apps.py contient plus d'une sous-classe AppConfig, Django en cherchera une seule où AppConfig.default est True. Si aucune sous-classe AppConfig n'est trouvée, la classe AppConfig de base sera utilisée. Alternativement, INSTALLED_APPS peut contenir le chemin en pointillé vers une classe de configuration pour la spécifier explicitement :

Personnalisation du type de clés primaires

Lors de la définition d'un modèle, si aucun champ dans un modèle n'est défini avec primary_key=True, une clé primaire implicite est ajoutée. Le type de cette clé primaire implicite peut maintenant être contrôlé via le paramètre DEFAULT_AUTO_FIELD et l'attribut AppConfig.default_auto_field. Il n'est plus nécessaire de remplacer les clés primaires dans tous les modèles.

En conservant le comportement historique, la valeur par défaut de DEFAULT_AUTO_FIELD est AutoField. À partir de la version 3.2, les nouveaux projets sont générés avec DEFAULT_AUTO_FIELD défini sur BigAutoField. De même, les nouvelles applications sont générées avec AppConfig.default_auto_field défini sur BigAutoField. Selon les responsables du projet Django, dans une prochaine version de Django, la valeur par défaut de DEFAULT_AUTO_FIELD sera remplacée par BigAutoField.

Pour éviter des migrations non désirées à l'avenir, il est recommandé de définir explicitement DEFAULT_AUTO_FIELD à AutoField :...