Après un an de développement, la version importante du langage de programmation Python 3.11 a été publiée. La nouvelle branche sera prise en charge pendant un an et demi, après quoi pendant trois ans et demi supplémentaires, des correctifs seront générés pour éliminer les vulnérabilités.
Parallèlement, les tests alpha de la branche Python 3.12 ont commencé (conformément au nouveau calendrier de développement, les travaux sur une nouvelle branche commencent cinq mois avant la sortie de la branche précédente et atteignent le stade des tests alpha au moment de la prochaine version ). La branche Python 3.12 sera en version alpha pendant sept mois, durant lesquels de nouvelles fonctionnalités seront ajoutées et des bugs corrigés. Après cela, les versions bêta seront testées pendant trois mois, pendant lesquels l'ajout de nouvelles fonctionnalités sera interdit et toute l'attention sera portée à la correction des bugs. Au cours des deux derniers mois précédant la sortie, la branche sera au stade de la release candidate, au cours de laquelle la stabilisation finale sera effectuée.
Les nouveaux ajouts à Python 3.11 incluent :
- Un travail important a été réalisé pour optimiser les performances. La nouvelle branche inclut des changements liés à l'accélération et au déploiement en ligne des appels de fonctions, à l'utilisation d'interpréteurs rapides d'opérations standards (x+x, x*x, xx, a[i], a[i] = z, f(arg) C( arg), o.method(), o.attr = z, *seq), ainsi que les optimisations préparées par les projets Cinder et HotPy. Selon le type de charge, la vitesse d'exécution du code augmente de 10 à 60 %. En moyenne, les performances de la suite de tests pyperformance ont augmenté de 25 %.
Le mécanisme de mise en cache du bytecode a été repensé, ce qui a réduit le temps de démarrage de l'interpréteur de 10 à 15 %. Les objets avec code et bytecode sont désormais alloués statiquement par l'interpréteur, ce qui a permis d'éliminer les étapes de désorganisation du bytecode extrait du cache et de conversion des objets avec code pour les placer en mémoire dynamique.
- Lors de l'affichage des traces d'appels dans les messages de diagnostic, il est désormais possible d'afficher des informations sur l'expression à l'origine de l'erreur (auparavant, seule la ligne était mise en surbrillance sans préciser quelle partie de la ligne provoquait l'erreur). Des informations de trace étendues peuvent également être obtenues via l'API et utilisées pour mapper des instructions de bytecode individuelles à une position spécifique dans le code source à l'aide de la méthode codeobject.co_positions() ou de la fonction API C PyCode_Addr2Location(). Ce changement facilite grandement le débogage des problèmes liés aux objets de dictionnaire imbriqués, aux appels de fonctions multiples et aux expressions arithmétiques complexes. Traceback (dernier appel le plus récent) : Fichier "calculation.py", ligne 54, en résultat = (x/y/z) * (a/b/c) ~~~~~~^~~ ZeroDivisionError : division par zéro
- Ajout de la prise en charge des groupes d'exceptions, donnant au programme la possibilité de générer et de traiter plusieurs exceptions différentes à la fois. Pour regrouper plusieurs exceptions et les déclencher ensemble, de nouveaux types d'exceptions ExceptionGroup et BaseExceptionGroup ont été proposés, et l'expression « except* » a été ajoutée pour mettre en évidence les exceptions individuelles d'un groupe.
- La méthode add_note() a été ajoutée à la classe BaseException, vous permettant de joindre une note textuelle à l'exception, par exemple en ajoutant des informations contextuelles qui ne sont pas disponibles lorsque l'exception est levée.
- Ajout d'un type Self spécial pour représenter la classe privée actuelle. Self peut être utilisé pour annoter des méthodes qui renvoient une instance de sa classe d'une manière plus simple qu'en utilisant TypeVar. class MyLock : def __enter__(self) -> Self : self.lock() return self
- Ajout d'un type LiteralString spécial qui ne peut inclure que des chaînes littérales compatibles avec le type LiteralString (c'est-à-dire des chaînes nues et LiteralString, mais pas des chaînes str arbitraires ou combinées). Le type LiteralString peut être utilisé pour limiter le passage d'arguments de chaîne aux fonctions, la substitution arbitraire de parties de chaînes pouvant conduire à des vulnérabilités, par exemple lors de la génération de chaînes pour des requêtes SQL ou des commandes shell. def run_query(sql : LiteralString) -> ... ... def caller (arbitraire_string : str, query_string : LiteralString, table_name : LiteralString, ) -> Aucun : run_query("SELECT * FROM Students") # ok run_query(literal_string) # ok run_query( "SELECT * FROM" + literal_string) # ok run_query(arbitrary_string) # Erreur run_query( # Erreur f"SELECT * FROM étudiants WHERE nom = {arbitrary_string}" )
- Le type TypeVarTuple a été ajouté, permettant l'utilisation de variables génériques, contrairement à TypeVar, qui couvrent non pas un type, mais un nombre arbitraire de types.
- La bibliothèque standard inclut le module tomllib avec des fonctions d'analyse du format TOML.
- Il est possible de marquer des éléments individuels des dictionnaires typés (TypedDict) avec des étiquettes Required et NotRequired pour déterminer les champs obligatoires et facultatifs (par défaut, tous les champs déclarés sont obligatoires si le paramètre total n'est pas défini sur False). class Movie(TypedDict) : titre : str année : NotRequired[int] m1 : Film = {"titre": "Black Panther", "année": 2018} # OK m2 : Film = {"titre": "Star Wars" } # OK (le champ année est optionnel) m3 : Film = {« année » : 2022} # Erreur, le champ titre obligatoire n'est pas renseigné)
- La classe TaskGroup a été ajoutée au module asyncio avec l'implémentation d'un gestionnaire de contexte asynchrone qui attend la fin d'un groupe de tâches. L'ajout de tâches à un groupe se fait à l'aide de la méthode create_task(). async def main() : async avec asyncio.TaskGroup() comme tg : task1 = tg.create_task(some_coro(...)) task2 = tg.create_task(another_coro(...)) print("Les deux tâches sont terminées maintenant .")
- Ajout du décorateur @dataclass_transform pour les classes, méthodes et fonctions. Lorsqu'il est spécifié, le système de vérification de type statique traite l'objet comme s'il utilisait le décorateur @dataclasses.dataclass. Dans l'exemple ci-dessous, la classe CustomerModel, lors de la vérification des types, sera traitée de la même manière qu'une classe avec le décorateur @dataclasses.dataclass, c'est-à-dire comme ayant une méthode __init__ qui accepte les variables id et name. @dataclass_transform() classe ModelBase : ... classe CustomerModel(ModelBase) : id : int nom : str
- Dans les expressions régulières, la possibilité d'utiliser le regroupement atomique ((?>...)) et les quantificateurs possessifs (*+, ++, ?+, {m,n}+) a été ajoutée.
- Ajout de l'option de ligne de commande "-P" et de la variable d'environnement PYTHONSAFEPATH pour désactiver l'attachement automatique des chemins de fichiers potentiellement dangereux à sys.path.
- L'utilitaire py.exe pour la plate-forme Windows a été considérablement amélioré, ajoutant la prise en charge de la syntaxe « -V : ». / " en plus de "- . "
- De nombreuses macros de l'API C sont converties en fonctions en ligne régulières ou statiques.
- Les modules uu, cgi, pipes, crypt, aifc, chunk, msilib, telnetlib, audioop, nis, sndhdr, imghdr, nntplib, spwd, xdrlib, cgitb, mailcap, ossaudiodev et sunau sont obsolètes et seront supprimés dans Python. Version 3.13. Suppression des fonctions PyUnicode_Encode*.
Source: opennet.ru