Django 3.0 s'accompagne du support d'ASGI ainsi que de MariaDB à partir de la version 10.1

Django 3.0 est disponible : le framework open source de développement Web en Python
s'accompagne du support d'ASGI ainsi que de MariaDB à partir de la version 10.1

Django est un framework Web libre et open source, écrit en Python, avec pour objectif principal de faciliter la création de sites Web complexes faisant appel à des bases de données. Il met donc l'accent sur la réutilisation des composants, le développement rapide et le principe de ne pas se répéter. Il est le plus utilisé parmi les frameworks basés sur le langage Python et pour de nombreux développeurs, Django est probablement l'une des premières raisons pour lesquelles ils utilisent Python.

La dernière version majeure du framework, la version 3.0, a été publiée le 2 décembre 2019. Django 3.0 prend en charge Python 3.6, 3.7 et 3.8. Cette version s'accompagne également du support officiel de MariaDB 10.1 et des versions ultérieures (la dernière version du fork communautaire de MySQL est MariaDB 10.4.10 qui a été publiée le 8 novembre 2019).

Support d'ASGI (Asynchronous Server Gateway Interface)

Avec Django 3.0, l'équipe voudrait mieux embrasser l'asynchrone ; cette version s'accompagne de la prise en charge l'exécution en tant qu'application ASGI. Cela vient s'ajouter au support du WSGI existant (Web Server Gateway Interface, une spécification qui définit une interface entre des serveurs et des applications web pour le langage Python). Django a l'intention de soutenir les deux (ASGI et WSGI) dans un avenir prévisible. Les fonctionnalités asynchrones ne seront toutefois disponibles que pour les applications fonctionnant sous ASGI.

Il n'est pas nécessaire de basculer vos applications à moins que vous ne vouliez commencer à expérimenter du code asynchrone, mais l'équipe a mis à disposition une documentation sur le déploiement avec ASGI si vous souhaitez en savoir plus.

Notez que, suite à cette modification, Django est désormais au courant des boucles d'événements asynchrones et bloque le code d'appel marqué comme « asynchrone non sécurisé » - telles que les opérations ORM - dans un contexte asynchrone. Si vous utilisiez déjà Django à partir de code asynchrone, cela pourrait se déclencher si vous ne le faisiez pas correctement. Si vous voyez une erreur SynchronousOnlyOperation, examinez attentivement votre code et déplacez les opérations de base de données dans un thread enfant synchrone.

Contraintes d'exclusion sur PostgreSQL

La nouvelle classe ExclusionConstraint permet d’ajouter des contraintes d’exclusion à PostgreSQL. Des contraintes sont ajoutées aux modèles à l'aide de l'option Meta.constraints.

Filtres d'expressions

Les expressions en sortie BooleanField peuvent désormais être utilisées directement dans les filtres QuerySet, sans avoir à être annotées, puis être filtrées à nouveau par rapport à l'annotation.

Pièce jointe 521373

Énumérations pour les choix de champs de modèle

Les types d'énumération personnalisés TextChoices, IntegerChoices et Choices sont désormais disponibles pour définir Field.choices. Les types TextChoices et IntegerChoices sont fournis pour les champs de texte et les champs entiers. La classe Choices permet de définir une énumération compatible pour d'autres types de données concrètes. Ces types d'énumérations personnalisées prennent en charge les étiquettes lisibles par l'homme qui peuvent être traduites et accessibles via une propriété de l'énumération ou de ses membres.

En fait, Django fournit des types d'énumération que vous pouvez sous-classer pour définir les choix de manière concise :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

from django.utils.translation import gettext_lazy as _   class Student(models.Model):   class YearInSchool(models.TextChoices): FRESHMAN = 'FR', _('Freshman') SOPHOMORE = 'SO', _('Sophomore') JUNIOR = 'JR', _('Junior') SENIOR = 'SR', _('Senior') GRADUATE = 'GR', _('Graduate')   year_in_school = models.CharField( max_length=2, choices=YearInSchool.choices, default=YearInSchool.FRESHMAN, )   def is_upperclass(self): return self.year_in_school in {YearInSchool.JUNIOR, YearInSchool.SENIOR}

---

Celles-ci fonctionnent comme enum de la bibliothèque standard de Python, mais avec quelques modifications :

• Les valeurs de membre enum sont un tuple d'arguments à utiliser lors de la construction du type de données concret. Django prend en charge l'ajout d'une valeur de chaîne supplémentaire à la fin de ce tuple à utiliser comme nom ou étiquette lisible par l'homme. Ainsi, dans la plupart des cas, la valeur du membre sera un tuple (valeur, étiquette). Si un tuple n'est pas fourni ou si le dernier élément n'est pas une chaîne (lazy), l'étiquette est automatiquement générée à partir du nom du membre.
• Une propriété .label est ajoutée aux valeurs pour renvoyer le nom lisible par l'homme.
• Un certain nombre de propriétés personnalisées sont ajoutées aux classes d'énumération - .choices, .labels, .values ​​et .names - pour faciliter l'accès aux listes de ces parties distinctes de l'énumération. Utilisez .choices comme valeur appropriée pour passer aux choix dans une définition de champ.
• L'utilisation de enum.unique() est appliquée pour garantir que les valeurs ne peuvent pas être définies plusieurs fois. Ceci est peu probable dans les choix pour un champ.

Fonctionnalités mineures

django.contrib.admin

• Ajout de la prise en charge de l'attribut admin_order_field sur les propriétés dans ModelAdmin.list_display.
• La nouvelle méthode ModelAdmin.get_inlines() permet de spécifier les inlines en fonction de la demande ou de l'instance de modèle.
• La bibliothèque Select2 est mise à niveau de la version 4.0.3 à 4.0.7.
• jQuery est mis à niveau de la version 3.3.1 à 3.4.1.

Commandes de gestion

• La nouvelle option compilemessages --ignore permet d’ignorer des répertoires spécifiques lors de la recherche de fichiers .po à compiler.
• showmigrations --list affiche maintenant les dates / heures appliquées lorsque --verbosity est égal à 2 et plus.
• Sur PostgreSQL, dbshell prend désormais en charge les certificats TLS côté client.
• inspectdb introspecte maintenant OneToOneField lorsqu'une clé étrangère a une contrainte de clé unique ou primaire.
• La nouvelle option --skip-checks ignore les vérifications du système en cours avant d'exécuter la commande.
• Les options startapp --template et startproject --template prennent désormais en charge les modèles stockés dans les archives XZ (.tar.xz, .txz) et les archives LZMA (.tar.lzma, .tlz).

Tests

• Le nouvel argument Client test raise_request_exception permet de contrôler si les exceptions déclenchées lors de la demande doivent également l'être dans le test. La valeur par défaut est True pour la compatibilité ascendante. Si la valeur est False et qu'une exception se produit, le client de test renvoie une réponse 500 avec l'attribut exc_info, un tuple fournissant des informations sur l'exception qui s'est produite.
• Les tests et les scénarios de test à exécuter peuvent être sélectionnés par modèle de nom de test à l'aide de la nouvelle option test -k.
• La comparaison HTML, telle qu'utilisée par assertHTMLEqual(), traite désormais le texte, les références de caractère et les références d'entité faisant référence au même caractère comme équivalent.

Source : note de version