Django 3.1 est disponible, compatible avec Python 3.6, 3.7 et 3.8

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

L’équipe de développement de Django, le framework open source et libre pour la création de sites Web complexes faisant appel à des bases de données, a annoncé cette semaine la sortie de Django 3.1 compatible avec Python 3.6, 3.7 et 3.8. Cette nouvelle version introduit plusieurs nouvelles fonctionnalités et apporte quelques améliorations et correctifs de bogues. Django 3.1 contient des modifications qui ne sont pas rétrocompatibles, les fonctionnalités qui ont atteint la fin de leur cycle de dépréciation ont été abandonnées et d’autres ont entamé leur cycle de dépréciation. Voici ci-dessous les fonctionnalités clés de Django 3.1.

Vues asynchrones et support des intergiciels (middlewares)

À partir de la version 3.1, Django supporte désormais un chemin de requête qui est totalement asynchrone, y compris : des vues asynchrones, un middleware asynchrone, des tests asynchrones et un client de test. Pour commencer avec les vues asynchrones, vous devez déclarer une vue en utilisant “async def”. Toutes les fonctions asynchrones sont prises en charge, que vous travailliez en mode WSGI ou ASGI. Cela dit, il y aura des pénalités de performance avec le code asynchrone en mode WSGI. Il est aussi possible de faire un mélange de tout.

Selon la note de version de Django 3.1, vous êtes libre de mélanger les vues asynchrones et synchrones, le middleware et les tests autant que vous le souhaitez. Django s'assurera que vous vous retrouvez toujours dans le bon contexte d'exécution. Par rapport à l'ORM de Django, l’équipe de développement du framework a déclaré que la couche cache et d'autres éléments de code qui effectuent des appels réseau de longue durée ne prennent pas encore en charge l'accès asynchrone. Elle prévoit de prendre en charge ces éléments dans les prochaines versions.

En outre, elle a aussi ajouté que les vues asynchrones sont idéales. Cependant, si vous effectuez beaucoup d'appels API ou HTTP dans votre vue, vous pouvez maintenant faire nativement tous ces appels HTTP en parallèle pour accélérer considérablement l'exécution de votre vue.

Pièce jointe 576782

JSONField pour tous les backends de base de données supportés

Django 3.1 introduit models.JSONField forms.JSONField qui peut être utilisé sur tous les backends de base de données supportés. Les deux champs supportent les encodeurs et les décodeurs JSON personnalisés. Le champ model prend également en charge l'introspection, les recherches et les transformations qui étaient auparavant uniquement PostgreSQL. Si votre projet utilise django.contrib.postgres.fields.JSONField, avec le champ de formulaire et les transformations associées, vous devez vous adapter pour utiliser les nouveaux champs, et générer et appliquer une migration de base de données.

Pour l'instant, les anciens champs et transformations sont laissés en référence aux nouveaux et sont obsolètes à partir de cette version.

Paramètres DEFAULT_HASHING_ALGORITHM

À partir de Django 3.1, les jetons, cookies, sessions et signatures utilisent l'algorithme de hachage SHA-256. En outre, le nouveau paramètre transitoire DEFAULT_HASHING_ALGORITHM vous permet de spécifier l'algorithme de hachage par défaut à utiliser pour encoder les cookies, les jetons de réinitialisation de mot de passe dans le site d'administration, les sessions utilisateur et les signatures créées par django.core.signing.Signer et django.core.signing.dumps(). Si vous mettez à jour plusieurs instances d'un même projet vers Django 3.1, vous devez effectuer quelques réglages.

Vous devez régler le paramètre DEFAULT_HASHING_ALGORITHM sur “sha1” pendant la transition, afin de permettre la compatibilité avec les anciennes versions de Django. Une fois la transition vers la version 3.1 terminée, vous pouvez arrêter de passer outre ce paramètre. Le support des tokens, cookies, sessions et signatures qui utilisent l'algorithme SHA-1 sera supprimé dans Django 4.0.

Fonctionnalités mineures

django.contrib.admin

• le nouveau paramètre django.contrib.admin.EmptyFieldListFilter pour ModelAdmin.list_filter permet de filtrer sur les valeurs vides (chaînes vides et nulles) dans la vue de la liste des modifications de l'administrateur ;
• les filtres dans la barre latérale droite de la vue de la liste des modifications de l'administrateur contiennent maintenant un lien pour effacer tous les filtres ;
• l'administrateur dispose maintenant d'une barre latérale sur des écrans plus grands pour faciliter la navigation. Elle est activée par défaut, mais peut être désactivée en utilisant un AdminSite personnalisé et en réglant AdminSite.enable_nav_sidebar sur False.

django.contrib.auth

• le nombre d'itérations par défaut pour PBKDF2 passe de 180 000 à 216 000 ;
• le nouveau paramètre PASSWORD_RESET_TIMEOUT permet de définir le nombre de secondes pendant lesquelles un lien de réinitialisation de mot de passe est valable. Ceci est encouragé au lieu du paramètre PASSWORD_RESET_TIMEOUT_DAYS qui est obsolète et qui sera supprimé dans Django 4.0 ;
• le mécanisme de réinitialisation du mot de passe utilise désormais l'algorithme de hachage SHA-256. La prise en charge des jetons utilisant l'ancien algorithme de hachage est maintenue jusqu'à la version 4.0 de Django ;
• AbstractBaseUser.get_session_auth_hash() utilise désormais l'algorithme de hachage SHA-256. La prise en charge des sessions utilisateur utilisant l'ancien algorithme de hachage est maintenue jusqu'à Django 4.0.

Cache

• le décorateur cache_control() et la méthode patch_cache_control() prennent désormais en charge plusieurs noms de champs dans la directive no-cache pour l'en-tête Cache-Control ;
• delete() renvoie maintenant True si la clé a été supprimée avec succès, False sinon.

Internationalisation

• le paramètre LANGUAGE_COOKIE_SAMESITE permet maintenant à la valeur “None” d'indiquer explicitement que le cookie est envoyé avec toutes les requêtes du même site ou de sites différents ;
• ajout de la prise en charge et des traductions pour les langues algérienne, arabe, igbo, kirghize, tadjik et turkmène.

Source : Note de version Django 3.1

Et vous ?

:fleche: Que pensez-vous des nouveautés de Django 3.1 ?

Voir aussi

:fleche: 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

:fleche: Django 2.2 est disponible au téléchargement : un aperçu des nouveautés du framework open source de développement Web en Python

:fleche: Django 2.0 est disponible en version stable. Quelles sont les nouveautés dans cette version du framework Web écrit en Python ?