Discussion :

[Anthony]

Une nouvelle version alpha de Python 3.12, plus rapide et plus légère, est désormais disponible, et apporte plusieurs améliorations au niveau du multitraitement et de la gestion des erreurs

La version 3.12.0a7 de Python a été publiée le 7 mai 2023, avec des améliorations en termes de vitesse et d'efficacité.

Les développeurs principaux ont exposé les améliorations lors de la convention PyCon de cette année à Salt Lake City (Utah), notamment les efforts visant à réduire l'utilisation de la mémoire de Python, à rendre l'interpréteur plus rapide et à optimiser la compilation pour obtenir un code plus efficace :

Les sous-interpréteurs sont un mécanisme par lequel le moteur d'exécution de Python peut avoir plusieurs interpréteurs fonctionnant ensemble à l'intérieur d'un seul processus, par opposition à chaque interpréteur isolé dans son propre processus (le mécanisme actuel de multiprocessing)... Bien que les sous-interpréteurs soient disponibles dans le moteur d'exécution de Python depuis un certain temps, ils n'ont pas eu d'interface pour l'utilisateur final. De plus, l'état désordonné des composants internes de Python n'a pas permis d'utiliser les sous-interpréteurs de manière efficace. Avec Python 3.12, le développeur principal de Python, Eric Snow, et sa cohorte ont suffisamment nettoyé les éléments internes de Python pour rendre les sous-interpréteurs utiles, et ils ont ajouté un module minimal à la bibliothèque standard de Python, appelé interpréteurs. Les programmeurs disposent ainsi d'un moyen rudimentaire de lancer des sous-interpréteurs et d'y exécuter du code.

Les premières expériences de Snow avec les sous-interpréteurs ont permis d'obtenir des performances nettement supérieures à celles du threading et du multiprocessing. Un exemple, un simple service web qui effectuait des tâches liées au processeur, atteignait un maximum de 100 requêtes par seconde avec les threads et de 600 avec le multiprocessing. Mais avec les sous-interpréteurs, il a obtenu 11 500 requêtes, avec une baisse minime, voire nulle, lorsqu'il a été étendu depuis un seul client. Le module d'interprétation a des fonctionnalités très limitées pour l'instant, et il manque de mécanismes robustes pour partager l'état entre les sous-interpréteurs. Mais Snow pense que d'ici Python 3.13, beaucoup plus de fonctionnalités apparaîtront, et dans l'intervalle, les développeurs sont encouragés à expérimenter...

Python 3.11 a introduit de nouveaux bytecodes dans l'interpréteur, appelés instructions adaptatives. Ces instructions peuvent être remplacées automatiquement au moment de l'exécution par des versions spécialisées pour un type Python donné, un processus appelé quickening. Cela évite à l'interpréteur d'avoir à rechercher les types d'objets, ce qui accélère considérablement le processus. Par exemple, si une opération d'addition donnée prend régulièrement en compte deux entiers, cette instruction peut être remplacée par une autre qui suppose que les opérandes sont tous deux des entiers... Python 3.12 dispose de plus de codes opérationnels de spécialisation adaptative...

Et à partir de Python 3.12, les en-têtes d'objets utilisent désormais 96 octets, soit "un peu moins de la moitié de ce qu'ils étaient auparavant".

Résumé des points forts de la version

Nouvelles fonctionnalités de typage

• PEP 688 : Rendre le protocole de tampon accessible dans Python
• PEP 692 : Utilisation de TypedDict pour un typage **kwargs plus précis
• PEP 698 : Surcharge du décorateur pour le typage statique

Dépréciations, suppressions ou restrictions importantes

• PEP 623 : Suppression de wstr de l'Unicode
• PEP 632 : Suppression du paquet distutils

Messages d'erreur améliorés

• Les modules de la bibliothèque standard sont maintenant potentiellement suggérés dans les messages d'erreur affichés par l'interpréteur lorsqu'une NameError est remontée au niveau supérieur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
>>> sys.version_info
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'sys' is not defined. Did you forget to import 'sys'?

• Amélioration de la suggestion d'erreur pour les exceptions NameError pour les instances. Maintenant, si une NameError est relevée dans une méthode et que l'instance a un attribut qui est exactement égal au nom dans l'exception, la suggestion inclura self.<NAME> au lieu de la correspondance la plus proche dans la portée de la méthode.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
>>> class A:
...   def __init__(self):
...       self.blech = 1
...
...   def foo(self):
...       somethin = blech

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
>>>A().foo()
  File "<stdin>", line 1
    somethin = blech
              ^^^^^
NameError: name 'blech' is not defined. Did you mean: 'self.blech'?

• Amélioration du message d'erreur SyntaxError lorsque l'utilisateur tape import x from y au lieu de from y import x.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
>>>import a.y.z from b.y.z
  File "<stdin>", line 1
    import a.y.z from b.y.z
    ^^^^^^^^^^^^^^^^^^^^^^^
SyntaxError: Did you mean to use 'from ... import ...' instead?

• Les exceptions ImportError soulevées en cas d'échec de l'instruction from <module> import <name> incluent désormais des suggestions pour la valeur de <name> en fonction des noms disponibles dans <module>.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
>>> from collections import chainmap
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name 'chainmap' from 'collections'. Did you mean: 'ChainMap'?

Nouvelles fonctionnalités

• Ajout de la prise en charge par Python du profileur Linux perf via la nouvelle variable d'environnement PYTHONPERFSUPPORT, la nouvelle option de ligne de commande -X perf, ainsi que les nouvelles API sys.activate_stack_trampoline(), sys.deactivate_stack_trampoline(), et sys.is_stack_trampoline_active().
• Les méthodes d'extraction dans tarfile, et shutil.unpack_archive(), ont un nouvel argument filtre qui permet de limiter les fonctionnalités de tar qui peuvent être surprenantes ou dangereuses, telles que la création de fichiers en dehors du répertoire de destination. Voir Filtres d'extraction pour plus de détails. Dans Python 3.14, la valeur par défaut sera 'data'.

PEP 688 : Rendre le protocole de tampon accessible dans Python

La PEP 688 introduit un moyen d'utiliser le protocole de tampon à partir du code Python. Les classes qui implémentent la méthode __buffer__() sont maintenant utilisables comme types de tampons.

Le nouvel ABC (Abstract Base Classes) collections.abc.Buffer fournit un moyen standard de représenter les objets tampons, par exemple dans les annotations de type. Le nouvel enum inspect.BufferFlags représente les flags qui peuvent être utilisés pour personnaliser la création de tampons.

Nouvelles fonctionnalités liées aux indications de type

Cette section couvre les changements majeurs affectant les indications de type PEP 484 et le module typing.

PEP 692 : Utilisation de TypedDict pour un typage **kwargs plus précis

Le typage des **kwargs dans une signature de fonction, tel qu'introduit par le PEP 484, ne permettait des annotations valides que dans les cas où tous les **kwargs étaient du même type.

Cette PEP spécifie une manière plus précise de typer les **kwargs en s'appuyant sur les dictionnaires typés :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
from typing import TypedDict, Unpack
 
class Movie(TypedDict):
  name: str
  year: int
 
def foo(**kwargs: Unpack[Movie]): ...

Voir la PEP 692 pour plus de détails.

Source : Nouveautés dans Python 3.12

Et vous ?

Que pensez-vous des nouveautés apportées par la version 3.12 de Python ?

Quelles améliorations vous intéressent le plus ?

Voir aussi

Python est le langage de programmation le plus utilisé et il ne montre aucun signe de ralentissement, selon l'index TIOBE de janvier 2022

Python 3.11 est disponible et s'accompagne d'une amélioration de la vitesse, de meilleures gestion des erreurs, du type self ainsi que des notes d'exception

JetBrains lance le programme d'accès anticipé (EAP) à PyCharm 2023.1, la première mise à jour majeure de l'année de son EDI Python

[Anthony]

Python 3.12.0b1, la première des quatre versions bêta de la 3.12, a été publiée, et apporte de nouvelles fonctionnalités ainsi que des corrections de bogues

Python 3.12 est toujours en cours de développement. Cette version, 3.12.0b1, est la première des quatre versions bêta de la 3.12.

Les versions bêta sont destinées à donner à l'ensemble de la communauté la possibilité de tester les nouvelles fonctionnalités et les corrections de bogues, et de préparer leurs projets à prendre en charge la nouvelle version.

Les responsables de projets Python tiers sont vivement encouragés à tester la version 3.12 au cours de la phase bêta et à signaler dès que possible les problèmes constatés au Python bug tracker (https://github.com/python/cpython/issues). Bien qu'il soit prévu que la version soit complète au début de la phase bêta, il est possible que des fonctionnalités soient modifiées ou, dans de rares cas, supprimées jusqu'au début de la phase de la version candidate (lundi 2023-07-31). L'objectif est de n'avoir aucun changement d'ABI après la bêta 4 et aussi peu de changements de code que possible après la 3.12.0rc1, la première version candidate. Pour y parvenir, il sera extrêmement important de faire connaître la 3.12 autant que possible pendant la phase bêta.

N'oubliez pas qu'il s'agit d'une version préliminaire et que son utilisation n'est pas recommandée pour les environnements de production.

Principales nouveautés de la série 3.12 par rapport à la 3.11

Voici quelques-unes des principales nouveautés et modifications de Python 3.12 :

• Nouvelle syntaxe d'annotation de type pour les classes génériques (PEP 695).
• Analyse plus souple des f-string, permettant de nombreuses choses auparavant interdites (PEP 701).
• Des messages d'erreur encore améliorés. Plus d'exceptions potentiellement causées par des fautes de frappe sont maintenant suggérées à l'utilisateur.
• De nombreuses améliorations, petites et grandes, des performances (comme PEP 709).
• Prise en charge du profileur Linux perf pour signaler les noms de fonctions Python dans les traces.
• Les membres wstr et wstr_length de l'implémentation C des objets unicode ont été supprimés, conformément à la PEP 623.
• Dans le module unittest, un certain nombre de méthodes et de classes dépréciées depuis longtemps ont été supprimées. (Elles étaient dépréciées depuis Python 3.1 ou 3.2).
• Les modules smtpd et distutils, obsolètes, ont été supprimés (voir PEP 594 et PEP 632). Le paquet setuptools (installé par défaut dans virtualenvs et dans de nombreux autres endroits) continue de fournir le module distutils.
• Un certain nombre d'autres fonctions, classes et méthodes anciennes, obsolètes et dépréciées ont été supprimées.
• Les séquences d'échappement backslash invalides dans les chaînes de caractères sont désormais signalées par SyntaxWarning au lieu de DeprecationWarning, ce qui les rend plus visibles. (Elles deviendront des erreurs de syntaxe à l'avenir).
• La représentation interne des entiers a été modifiée en vue d'améliorer les performances. (Cela ne devrait pas affecter la plupart des utilisateurs puisqu'il s'agit d'un détail interne, mais cela peut poser des problèmes pour le code généré par Cython).

Pour plus de détails sur les changements apportés à Python 3.12, voir What's new in Python 3.12. La prochaine préversion de Python 3.12 sera la 3.12.0b2, actuellement prévue pour le 2023-05-29.

Source : Python 3.12.0b1

Et vous ?

Qu'en pensez-vous ?

Voir aussi

Une nouvelle version alpha de Python 3.12, plus rapide et plus légère, est désormais disponible, et apporte plusieurs améliorations au niveau du multitraitement et de la gestion des erreurs

Python 3.11 est disponible et s'accompagne d'une amélioration de la vitesse, de meilleures gestion des erreurs, du type self ainsi que des notes d'exception

[Jade Emy]

Python 3.12 : la dernière version apporte des modifications du langage et de la bibliothèque standard, elle comporte aussi une amélioration des messages d'erreur

Python 3.12 est la dernière version stable du langage de programmation Python, avec un mélange de modifications du langage et de la bibliothèque standard. Les modifications apportées à la bibliothèque se concentrent sur le nettoyage des API obsolètes, la facilité d'utilisation et la correction. À noter que le paquet distutils a été supprimé de la bibliothèque standard. La prise en charge des systèmes de fichiers dans os et pathlib a fait l'objet d'un certain nombre d'améliorations, et plusieurs modules sont plus performants.

Les modifications apportées au langage se concentrent sur la facilité d'utilisation : les f-strings ont été débarrassées de nombreuses limitations et les suggestions "Did you mean ..." continuent de s'améliorer. La nouvelle syntaxe des paramètres de type et la déclaration de type améliorent l'ergonomie de l'utilisation des types génériques et des alias de type avec les vérificateurs de types statiques.

PEP 695 : Syntaxe des paramètres de type

Les classes et fonctions génériques de la PEP 484 étaient déclarées à l'aide d'une syntaxe verbeuse qui ne permettait pas de déterminer clairement la portée des paramètres de type et nécessitait des déclarations explicites de variance.

La PEP 695 introduit une nouvelle méthode, plus compacte et plus explicite, pour créer des classes et des fonctions génériques :

La nouvelle syntaxe permet de déclarer des paramètres TypeVarTuple et ParamSpec, ainsi que des paramètres TypeVar avec des limites ou des contraintes :

La valeur des alias de type et les contraintes des variables de type créées à l'aide de cette syntaxe ne sont évaluées qu'à la demande. Cela signifie que les alias de type peuvent faire référence à d'autres types définis plus loin dans le fichier.

Les paramètres de type déclarés au moyen d'une liste de paramètres de type sont visibles dans la portée de la déclaration et dans toute portée imbriquée, mais pas dans la portée extérieure. Par exemple, ils peuvent être utilisés dans les annotations de type pour les méthodes d'une classe générique ou dans le corps de la classe. Toutefois, ils ne peuvent pas être utilisés dans la portée du module après la définition de la classe.

Afin de prendre en charge cette sémantique de portée, un nouveau type de portée est introduit, la portée d'annotation. Les portées d'annotation se comportent pour la plupart comme les portées de fonction, mais interagissent différemment avec les portées de classe qui les entourent. Dans Python 3.13, les annotations seront également évaluées dans les portées d'annotation.

PEP 701 : Formalisation syntaxique des f-strings

La PEP 701 lève certaines restrictions sur l'utilisation des f-strings. Les composants d'expression à l'intérieur des f-strings peuvent maintenant être n'importe quelle expression Python valide, y compris les chaînes réutilisant le même guillemet que le f-strings contenant, les expressions multi-lignes, les commentaires, les antislashs, et les séquences d'échappement unicode. Voyons cela en détail :

• Réutilisation des guillemets : dans Python 3.11, la réutilisation des mêmes guillemets que la f-string contenante soulève une SyntaxError, obligeant l'utilisateur à utiliser d'autres guillemets disponibles (comme des guillemets doubles ou triples si la chaîne f utilise des guillemets simples). Dans Python 3.12, vous pouvez maintenant faire des choses comme ceci :
  
  
  
• Expressions et commentaires sur plusieurs lignes : Dans Python 3.11, les expressions f-string doivent être définies sur une seule ligne, même si l'expression à l'intérieur de la f-string pourrait normalement s'étendre sur plusieurs lignes (comme les listes littérales définies sur plusieurs lignes), ce qui les rend plus difficiles à lire. Dans Python 3.12, vous pouvez désormais définir des chaînes f s'étendant sur plusieurs lignes et ajouter des commentaires en ligne :
  
  
  
• Barres obliques inversées et caractères unicode : avant Python 3.12, les expressions f-string ne pouvaient contenir aucun caractère \. Cela affectait également les séquences d'échappement unicode (telles que \N{snowman}) car elles contiennent la partie \N qui, auparavant, ne pouvait pas faire partie des composants d'expression des chaînes f. Désormais, vous pouvez définir des expressions comme celles-ci:
  
  
  

Un effet secondaire positif de la façon dont cette fonctionnalité a été implémentée (en analysant les chaînes f avec l'analyseur PEG) est que les messages d'erreur pour les chaînes f sont maintenant plus précis et incluent l'emplacement exact de l'erreur. Dans Python 3.12, comme les f-strings sont analysées avec l'analyseur PEG, les messages d'erreur peuvent être plus précis et afficher la ligne entière :

PEP 684 : Une GIL par interprète

La PEP 684 introduit une GIL par interprète, de sorte que les sous-interprètes peuvent désormais être créés avec une GIL unique par interprète. Cela permet aux programmes Python de tirer pleinement parti de plusieurs cœurs de processeur.Ceci n'est actuellement disponible qu'à travers l'API C, bien qu'une API Python soit prévue pour la version 3.13.

Utilisez la nouvelle fonction Py_NewInterpreterFromConfig() pour créer un interpréteur avec sa propre GIL :

PEP 669 : Surveillance à faible impact pour CPython

Le PEP 669 définit une nouvelle API pour les profileurs, les débogueurs et d'autres outils pour surveiller les événements dans CPython. Elle couvre une large gamme d'événements, y compris les appels, les retours, les lignes, les exceptions, les sauts, et plus encore. Cela signifie que vous ne payez que pour ce que vous utilisez, fournissant un support pour les débogueurs et les outils de couverture avec un surcoût proche de zéro.

PEP 688 :Rendre le protocole de tampon accessible en Python

La PEP 688 introduit un moyen d'utiliser le protocole de tampon à partir du code Python. Les classes qui implémentent la méthode __buffer__() sont désormais utilisables en tant que types de tampons.

Le nouvel ABC collections.abc.Buffer fournit un moyen standard de représenter les objets tampons, par exemple dans les annotations de type. Le nouvel enum inspect.BufferFlags représente les drapeaux qui peuvent être utilisés pour personnaliser la création de tampons.

PEP 709 : Inlining de la compréhension

Les compréhensions de dictionnaires, de listes et d'ensembles sont désormais intégrées, plutôt que de créer un nouvel objet fonction à usage unique pour chaque exécution de la compréhension. Cela permet d'accélérer l'exécution d'une compréhension jusqu'à deux fois.

Les variables d'itération de la compréhension restent isolées et n'écrasent pas une variable du même nom dans la portée extérieure, et ne sont pas visibles après la compréhension. L'incrustation entraîne quelques changements de comportement visibles :

• Il n'y a plus de cadre séparé pour la compréhension dans les tracesbacks, et le traçage/profilage ne montre plus la compréhension comme un appel de fonction.
  
• Le module symtable ne produira plus de tables de symboles enfants pour chaque compréhension ; à la place, les locales de la compréhension seront incluses dans la table de symboles de la fonction parente.
  
• L'appel à locals() à l'intérieur d'une compréhension inclut désormais des variables extérieures à la compréhension et n'inclut plus la variable synthétique .0 pour l'"argument" de la compréhension.
  
• Une compréhension itérant directement sur locals() (par exemple [k for k in locals()]) peut voir "RuntimeError : dictionary changed size during iteration" lorsqu'elle est exécutée sous traçage (par exemple, mesure de la couverture du code). Il s'agit du même comportement que celui observé dans for k in locals() :. Pour éviter l'erreur, il faut d'abord créer une liste de clés sur lesquelles itérer : keys = list(locals()) ; [k for k in keys].

Amélioration des messages d'erreur

• Les modules de la bibliothèque standard sont maintenant potentiellement suggérés dans les messages d'erreur affichés par l'interpréteur lorsqu'une NameError est remontée au niveau supérieur.
  
  
  
• Amélioration de la suggestion d'erreur pour les exceptions NameError pour les instances. Maintenant, si une NameError est levée dans une méthode et que l'instance a un attribut qui est exactement égal au nom dans l'exception, la suggestion inclura self.<NAME> au lieu de la correspondance la plus proche dans la portée de la méthode.
  
  
  
• Améliorer le message d'erreur SyntaxError lorsque l'utilisateur tape import x from y au lieu de from y import x.
  
  
  
• Les exceptions ImportError soulevées par l'échec de from <module> import <nom> incluent maintenant des suggestions pour la valeur de <nom> basées sur les noms disponibles dans <module>.
  
  
  

PEP 692 : Utilisation de TypedDict pour un typage plus précis des **kwargs

Le typage des **kwargs dans la signature d'une fonction, tel qu'introduit par la PEP 484, ne permettait des annotations valides que dans les cas où tous les **kwargs étaient du même type.

La PEP 692 spécifie une manière plus précise de typer les **kwargs en s'appuyant sur les dictionnaires typés :

PEP 698 : Décorateur de surcharge pour le typage statique

Un nouveau décorateur typing.override() a été ajouté au module de typage.Il indique aux vérificateurs de type que la méthode est destinée à remplacer une méthode d'une superclasse.Cela permet aux vérificateurs de type de détecter les erreurs lorsqu'une méthode destinée à remplacer une méthode d'une classe de base ne le fait pas.

Cet article ne prétend pas fournir une spécification complète de toutes les nouvelles fonctionnalités, mais donne plutôt une vue d'ensemble pratique. Pour plus de détails, vous pouvez voir dans la source.

Source : Python

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Une nouvelle version alpha de Python 3.12, plus rapide et plus légère, est désormais disponible et apporte plusieurs améliorations au niveau du multitraitement et de la gestion des erreurs

Python 3.12.0b1, la première des quatre versions bêta de la 3.12, a été publiée et apporte de nouvelles fonctionnalités ainsi que des corrections de bogues

Le plan de travail pour la future version 3.13 de Python a été dévoilé et vise la réduction d'au moins 50 % du temps passé dans l'interpréteur ainsi qu'une meilleure gestion de la mémoire