1 pièce(s) jointe(s)
La version 3.2 du framework Django est disponible, avec la découverte automatique d'AppConfig
La version 3.2 du framework Django est disponible, avec la découverte automatique d'AppConfig,
elle apporte des 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 :
Code:
1
2
3
4
5
| INSTALLED_APPS = [
...
'polls.apps.PollsAppConfig',
...
] |
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 :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
| DEFAULT_AUTO_FIELD = 'django.db.models.AutoField'
ou le configurer sur une base par application :
from django.apps import AppConfig
class MyAppConfig(AppConfig):
default_auto_field = 'django.db.models.AutoField'
name = 'my_app'
ou sur une base par modèle :
from django.db import models
class MyModel(models.Model):
id = models.AutoField(primary_key=True) |
Index fonctionnels
Les nouvelles expressions de position d’argument de Index() permettent de créer des index fonctionnels sur des expressions et des fonctions de base de données. Par exemple :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| from django.db import models
from django.db.models import F, Index, Value
from django.db.models.functions import Lower, Upper
class MyModel(models.Model):
first_name = models.CharField(max_length=255)
last_name = models.CharField(max_length=255)
height = models.IntegerField()
weight = models.IntegerField()
class Meta:
indexes = [
Index(
Lower('first_name'),
Upper('last_name').desc(),
name='first_last_name_idx',
),
Index(
F('height') / (F('weight') + Value(5)),
name='calc_idx',
),
] |
Les index fonctionnels sont ajoutés aux modèles à l'aide de l'option Meta.indexes.
Nouveaux décorateurs pour le module d'administration
Le nouveau décorateur display() permet d'ajouter facilement des options aux fonctions d'affichage personnalisées qui peuvent être utilisées avec list_display ou readonly_fields. De même, le nouveau décorateur action() permet d'ajouter facilement des options aux fonctions d'action qui peuvent être utilisées avec des actions.
L'utilisation du décorateur @display présente l'avantage qu'il est désormais possible d'utiliser le décorateur @property lorsqu'il est nécessaire de spécifier des attributs sur la méthode personnalisée. Auparavant, il était nécessaire d'utiliser la fonction property() après avoir attribué les attributs requis à la méthode. L'utilisation des décorateurs présente l'avantage de rendre ces options plus faciles à découvrir, car elles peuvent être suggérées par les utilitaires de complétion des éditeurs de code.
Django.contrib.admin
Avec la version 3.2 de Django, ModelAdmin.search_fields permet maintenant d'effectuer des recherches sur des phrases citées avec des espaces. Les champs liés en lecture seule sont maintenant rendus sous forme de liens navigables si des modèles cibles sont enregistrés dans admin. De plus, l'administration prend maintenant en charge la thématisation, et inclut un thème sombre qui est activé en fonction des paramètres du navigateur.
L'administrateur peut désormais installer une vue catch-all qui redirige les utilisateurs non authentifiés vers la page de connexion, que l'URL soit ou non valide. Cela permet de se protéger contre un éventuel problème de confidentialité lié à l'énumération des modèles. Bien que cela ne soit pas recommandé, il est possible de définir la nouvelle variable AdminSite.final_catch_all_view sur False pour désactiver la vue catch-all.
Django 3.2 et la sécurité
Le paramètre SECRET_KEY est maintenant vérifié pour une valeur valide lors du premier accès, plutôt que lors du premier chargement des paramètres. Cela permet d'exécuter des commandes de gestion qui ne dépendent pas du SECRET_KEY sans avoir besoin de fournir une valeur. Par conséquent, l'appel de configure() sans fournir un SECRET_KEY valide, puis l'accès à settings.SECRET_KEY déclenchera une exception ImproperlyConfigured.
Les nouvelles méthodes Signer.sign_object() et Signer.unsign_object() permettent de signer des structures de données complexes. En outre, les méthodes signing.dumps() et loads() deviennent des raccourcis pour TimestampSigner.sign_object() et unsign_object().
Django 3.2 et la pagination
La nouvelle méthode django.core.paginator.Paginator.get_elided_page_range() permet de générer une gamme de pages dont certaines valeurs sont élidées. S'il y a un grand nombre de pages, cela peut être utile pour générer un nombre raisonnable de liens de page dans un modèle.
Les commandes de gestion
Avec la version 3.2 de Django, loaddata prend maintenant en charge les éléments stockés dans des archives XZ (.xz) et LZMA (.lzma). dumpdata peut désormais compresser les données aux formats bz2, gz, lzma ou xz. makemigrations peut maintenant être appelé sans une connexion active à la base de données. Dans ce cas, la vérification d'un historique de migration cohérent est ignorée. BaseCommand.requires_system_checks permet désormais de spécifier une liste de balises. Les contrôles du système enregistrés dans les balises choisies seront vérifiés avant l'exécution de la commande. Dans les versions précédentes, toutes les vérifications du système étaient effectuées, ou aucune. La prise en charge de la sortie colorée du terminal sous Windows a été mise à jour. Divers environnements de terminaux modernes sont automatiquement détectés, et les options permettant d'activer la prise en charge dans d'autres cas sont améliorées.
Les modèles avec Django 3.2
Le nouveau paramètre no_key pour QuerySet.select_for_update(), supporté par PostgreSQL, permet d'acquérir des verrous plus faibles qui ne bloquent pas la création de lignes qui font référence à des lignes verrouillées par le biais d'une clé étrangère.
L'expression When() permet maintenant d'utiliser l'argument condition avec les lookups.
Les nouveaux attributs Index.include et UniqueConstraint.include permettent de créer des index de recouvrement et des contraintes uniques de recouvrement sur PostgreSQL 11+. Le nouvel attribut UniqueConstraint.opclasses permet de définir les classes d'opérateurs PostgreSQL.
La méthode QuerySet.update() respecte désormais la clause order_by() sur MySQL et MariaDB.
La nouvelle méthode QuerySet.alias() permet de créer des alias réutilisables pour les expressions qui n'ont pas besoin d'être sélectionnées, mais qui sont utilisées pour le filtrage, l'ordonnancement ou comme partie d'expressions complexes.
Django 3.2 est désigné comme une version de support à long terme et ne prend en charge que les versions Python 3.6, 3.7, 3.8 et 3.9. Elle recevra des mises à jour de sécurité pendant au moins trois ans après sa sortie. La prise en charge de la version LTS précédente, Django 2.2, prendra fin en avril 2022.
Source : Django
Et vous ?
:fleche: Quel langage utilisez-vous pour le développement Web ? Quel framework ?
:fleche: Avez-vous une expérience avec Python pour le web ?
:fleche: Quelle fonctionnalité vous intéresse le plus ?
:fleche: Quelles sont les améliorations apportées à Django 3.2 qui vous intéressent ?
Voir aussi :
:fleche: Le langage Python fête ses 30 ans d'existence avec une adoption toujours plus forte au sein des développeurs, ce succès serait dû à son caractère facile à apprendre et utilisable pour divers projets
:fleche: Guido Van Rossum, le créateur du langage de programmation Python, prend sa retraite, « ça a été une aventure incroyable », dit-il
:fleche: Django 3.1 est disponible, compatible avec Python 3.6, 3.7 et 3.8 et introduit JSONField pour tous les backends de base de données supportés
:fleche: RustPython, un interpréteur Python écrit en Rust et compatible avec WebAssembly, est disponible, pourrait-il rivaliser avec CPython ?
