Les nouveautés de Python 3.10

Version:

3.10.4

Date:

mai 25, 2022

Rédacteur:

Pablo Galindo Salgado

Cet article explique les nouvelles fonctionnalités de Python 3.10 par rapport à la version 3.9.

Pour plus de détails, voir le changelog.

Résumé – Points forts de la publication

Nouvelles fonctionnalités de syntaxe :

  • PEP 634, Filtrage par motifs structurels : spécification ;

  • PEP 635, Filtrage par motifs structurels : motivation et justification ;

  • PEP 636, Filtrage par motifs structurels : tutoriel ;

  • bpo-12782, Les gestionnaires de contextes entre parenthèses sont maintenant autorisés.

Nouvelles fonctionnalités dans la bibliothèque standard :

  • PEP 618, ajout de la vérification optionnelle de taille dans zip.

Améliorations de l'interpréteur :

  • PEP 626, numéros de lignes précis pour le débogage et les autres outils.

Nouvelles fonctionnalités de typage :

  • PEP 604, autorise l'écriture d'union de types sous la forme X | Y ;

  • PEP 613, alias de types explicites ;

  • PEP 612, variables de spécification de paramètres.

Obsolescences, retraits ou restrictions :

  • PEP 644, mise à jour de la version minimale d'OpenSSL à 1.1.1 ;

  • PEP 632, obsolescence du module distutils ;

  • PEP 623, obsolescence et préparation du retrait du membre wstr de PyUnicodeObject ;

  • PEP 624, retrait des API d'encodage Py_UNICODE ;

  • PEP 597, ajout de l'EncodingWarning optionnel

Nouvelles fonctionnalités

Gestionnaires de contextes entre parenthèses

Il est maintenant possible de mettre les gestionnaires de contexte entre parenthèses pour les répartir sur plusieurs lignes. Ceci permet le formatage d'une longue série de gestionnaires de contexte sur plusieurs lignes comme ce qui était préalablement possible avec les instructions d'importation. Par exemple, tous ces blocs sont maintenant valides :

with (CtxManager() as example):
    ...

with (
    CtxManager1(),
    CtxManager2()
):
    ...

with (CtxManager1() as example,
      CtxManager2()):
    ...

with (CtxManager1(),
      CtxManager2() as example):
    ...

with (
    CtxManager1() as example1,
    CtxManager2() as example2
):
    ...

il est aussi possible d'utiliser une virgule en fin de ligne à la fin du groupe entre parenthèses :

with (
    CtxManager1() as example1,
    CtxManager2() as example2,
    CtxManager3() as example3,
):
    ...

Cette nouvelle syntaxe utilise la capacité non-LL(1) du nouvel analyseur syntaxique. Voir PEP 617 pour plus de détails.

(contribution de Guido van Rossum, Pablo Galindo et Lysandros Nikolaou dans bpo-12782 et bpo-40334).

Meilleurs messages d'erreurs

SyntaxError

Pendant l'analyse syntaxique de code qui contient des parenthèses ou autres balises ouvrantes et fermantes, l'interpréteur inclut maintenant l'emplacement de la balise ou parenthèse non fermée plutôt que d'afficher SyntaxError: unexpected EOF while parsing ou d'indiquer un emplacement incorrect. Par exemple, considérez le code suivant (remarquez l'accolade '{' non-fermée) :

expected = {9: 1, 18: 2, 19: 2, 27: 3, 28: 3, 29: 3, 36: 4, 37: 4,
            38: 4, 39: 4, 45: 5, 46: 5, 47: 5, 48: 5, 49: 5, 54: 6,
some_other_code = foo()

Les versions précédentes de l’interpréteur indiquaient des emplacements qui portaient à confusion pour l'erreur de syntaxe :

File "example.py", line 3
    some_other_code = foo()
                    ^
SyntaxError: invalid syntax

mais dans Python 3.10, une erreur plus informative est levée :

File "example.py", line 1
    expected = {9: 1, 18: 2, 19: 2, 27: 3, 28: 3, 29: 3, 36: 4, 37: 4,
               ^
SyntaxError: '{' was never closed

De façon similaire, les erreurs impliquant des chaînes littérales non-fermées (avec simples ou triples apostrophes) pointent maintenant vers le début de la chaîne plutôt de mentionner la fin de ligne ou la fin du fichier.

Ces améliorations sont inspirées par un travail préalable sur l'interpréteur PyPy

(contribution de Pablo Galindo dans bpo-42864 et Batuhan Taskaya dans bpo-40176).

Les exceptions SyntaxError levées par l'interpréteur soulignent maintenant toute la portée de l'expression qui constitue l'erreur de syntaxe plutôt que seulement la position où le problème a été détecté. De cette façon, plutôt que d'afficher (avant Python 3.10) :

>>> foo(x, z for z in range(10), t, w)
  File "<stdin>", line 1
    foo(x, z for z in range(10), t, w)
           ^
SyntaxError: Generator expression must be parenthesized

Python 3.10 affiche maintenant l'exception comme ceci :

>>> foo(x, z for z in range(10), t, w)
  File "<stdin>", line 1
    foo(x, z for z in range(10), t, w)
           ^^^^^^^^^^^^^^^^^^^^
SyntaxError: Generator expression must be parenthesized

Cette amélioration est une contribution de Pablo Galindo dans bpo-43914.

Un nombre considérable de nouveaux messages spécialisés pour les exceptions SyntaxError a été incorporé. Certains des plus notables sont :

  • : manquant avant les blocs :

    >>> if rocket.position > event_horizon
  File "<stdin>", line 1
    if rocket.position > event_horizon
                                      ^
SyntaxError: expected ':'

    (contribution de Pablo Galindo dans bpo-42997) ;

  • Les n-uplets sans parenthèses dans les cibles de compréhensions :

    >>> {x,y for x,y in zip('abcd', '1234')}
  File "<stdin>", line 1
    {x,y for x,y in zip('abcd', '1234')}
     ^
SyntaxError: did you forget parentheses around the comprehension target?

    (contribution de Pablo Galindo dans bpo-43017) ;

  • virgules manquantes dans les littéraux de collections et entre les expressions ;

    >>> items = {
... x: 1,
... y: 2
... z: 3,
  File "<stdin>", line 3
    y: 2
       ^
SyntaxError: invalid syntax. Perhaps you forgot a comma?

    (contribution de Pablo Galindo dans bpo-43822) ;

  • types multiples d'Exception sans parenthèses :

    >>> try:
...     build_dyson_sphere()
... except NotEnoughScienceError, NotEnoughResourcesError:
  File "<stdin>", line 3
    except NotEnoughScienceError, NotEnoughResourcesError:
           ^
SyntaxError: multiple exception types must be parenthesized

    (contribution de Pablo Galindo dans bpo-43149) ;

  • : et valeurs manquantes dans les littéraux de dictionnaires :

    >>> values = {
... x: 1,
... y: 2,
... z:
... }
  File "<stdin>", line 4
    z:
     ^
SyntaxError: expression expected after dictionary key and ':'

>>> values = {x:1, y:2, z w:3}
  File "<stdin>", line 1
    values = {x:1, y:2, z w:3}
                        ^
SyntaxError: ':' expected after dictionary key

    (contribution de Pablo Galindo dans bpo-43823) ;

  • blocs try sans blocs except ou finally :

    >>> try:
...     x = 2
... something = 3
  File "<stdin>", line 3
    something  = 3
    ^^^^^^^^^
SyntaxError: expected 'except' or 'finally' block

    (contribution de Pablo Galindo dans bpo-44305) ;

  • utilisation de = au lieu de == dans les comparaisons :

    >>> if rocket.position = event_horizon:
  File "<stdin>", line 1
    if rocket.position = event_horizon:
                       ^
SyntaxError: cannot assign to attribute here. Maybe you meant '==' instead of '='?

    (contribution de Pablo Galindo dans bpo-43797)

  • utilisation de * dans les chaînes formatées (f-strings) :

    >>> f"Black holes {*all_black_holes} and revelations"
  File "<stdin>", line 1
    (*all_black_holes)
     ^
SyntaxError: f-string: cannot use starred expression here

    (contribution de Pablo Galindo dans bpo-41064).

IndentationError

Plusieurs exceptions IndentationError ont maintenant plus de contexte concernant le genre de bloc qui attendait une indentation. Ceci inclut l'emplacement de l'instruction :

>>> def foo():
...    if lel:
...    x = 2
  File "<stdin>", line 3
    x = 2
    ^
IndentationError: expected an indented block after 'if' statement in line 2

AttributeError

À l'impression d'une AttributeError, PyErr_Display() offre des suggestions de noms d'attributs similaires dans l'objet pour lequel l'exception a été levée :

>>> collections.namedtoplo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'collections' has no attribute 'namedtoplo'. Did you mean: namedtuple?

(contribution de Pablo Galindo dans bpo-38530).

Avertissement

notez que ceci ne fonctionne pas si PyErr_Display() n'est pas appelée pour afficher l'erreur, ce qui est le cas si une fonction d'affichage d'erreur personnalisée est utilisée. C'est un scénario typique avec certains interpréteurs interactifs comme IPython.

NameError

Quand elle affiche une NameError levée par l'interpréteur, PyErr_Display() offre des suggestions de variables qui ont un nom similaire dans la fonction de laquelle l’exception a été levée :

>>> schwarzschild_black_hole = None
>>> schwarschild_black_hole
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'schwarschild_black_hole' is not defined. Did you mean: schwarzschild_black_hole?

(contribution de Pablo Galindo dans bpo-38530).

Avertissement

notez que ceci ne fonctionne pas si PyErr_Display() n'est pas appelée pour afficher l'erreur, ce qui est le cas si une fonction d'affichage d'erreur personnalisée est utilisée. C'est un scénario typique avec certains interpréteurs interactifs comme IPython.

PEP 626 : numéros de lignes précis pour le débogage et les autres outils

La PEP 626 apporte des numéros de lignes plus précis pour le débogage, le profilage et les outils de mesure de couverture. Les événements de traçage, avec les numéros de ligne corrects, sont générés pour toutes les lignes de code exécutées et seulement pour celles-ci.

L'attribut f_lineno des objets cadres contient dorénavant le numéro de ligne attendu.

L'attribut co_lnotab des objets code est obsolète et sera retiré dans 3.12. Tout code qui doit convertir d'un décalage (offset) vers des numéros de ligne doit plutôt utiliser la nouvelle méthode co_lines().

PEP 634 : filtrage par motifs structurels

Le filtrage par motifs a été ajouté sous la forme d'une instruction match et d'instructions case pour les motifs avec des actions associées. Les motifs filtrent des séquences, des dictionnaires, des types de données et des instances de classes. Le filtrage par motifs permet aux programmes d'extraire de l'information de types de données complexes, faire du branchement selon la structure des données et réaliser des actions spécifiques en fonction des différentes formes des données.

Syntaxe et opérations

La syntaxe générique du filtrage par motifs est :

match subject:
    case <pattern_1>:
        <action_1>
    case <pattern_2>:
        <action_2>
    case <pattern_3>:
        <action_3>
    case _:
        <action_wildcard>

Une instruction match prend une expression et compare successivement sa valeur à différents filtres qui sont donnés comme un ou plusieurs blocs case. Plus précisément, le filtrage par motifs s'effectue par :

  1. l'utilisation de données qui ont un type et une forme (ici subject) ;

  2. l'évaluation de subject dans une instruction match ;

  3. l'application de chaque filtre sur subject dans des instructions case de haut en bas jusqu'à ce qu'un appariement soit confirmé ;

  4. l’exécution de l'action associée au filtre s'il y a appariement ;

  5. s'il n'y a aucun appariement et que le dernier case est un filtre attrape-tout _, l'action correspondante est exécutée. S'il n'y a aucun appariement ni filtre attrape-tout, le bloc match n'effectue aucune opération.

Approche déclarative

Le filtrage par motifs est peut-être connu des lecteurs par l'intermédiaire des langages C, Java ou JavaScript (et plusieurs autres langages), avec l'appariement simple d'un sujet (objet de données) à un littéral (filtre) avec l'instruction switch. Souvent, l'instruction switch est utilisée pour comparer des objets ou expressions à des instructions case qui contiennent des littéraux.

Des exemples plus puissants de filtrage par motifs sont présents dans des langages tels que Scala et Elixir. Avec le filtrage par motifs structurels, l'approche est « déclarative » et énonce les conditions (les motifs) pour apparier les données.

Bien qu'une série d'instructions « impératives » utilisant des instructions « if » imbriquées puisse être utilisée pour accomplir quelque chose de similaire au filtrage par motifs structurels, ceci est moins clair que l'approche « déclarative ». Cette dernière énonce les conditions à remplir pour réaliser un appariement grâce à ses filtres sur des motifs explicites. Bien que le filtrage par motifs structurels puisse être utilisé dans sa forme la plus simple pour comparer une variable à un littéral dans une instruction case, son intérêt réel en Python réside dans son traitement du sujet selon son type et sa forme.

Filtre simple : apparier à un littéral

Regardons cet exemple en tant que filtrage par motif dans sa forme la plus simple : une valeur, le sujet, est comparée à (ou « filtrée par ») plusieurs littéraux, les motifs. Dans l'exemple ci-dessous, status est le sujet de l'instruction match. Les filtres sont chacune des instructions case, où les littéraux représentent les codes de status des requêtes. Les actions associées au case sont exécutés suite à un appariement :

def http_error(status):
    match status:
        case 400:
            return "Bad request"
        case 404:
            return "Not found"
        case 418:
            return "I'm a teapot"
        case _:
            return "Something's wrong with the internet"

Si on passe 418 à status dans la fonction ci-haut, elle renvoie "I'm a teapot". Avec 500, l'instruction case qui contient _ apparie comme attrape-tout et la fonction renvoie "Something's wrong with the internet". Prenez note que dans le dernier bloc, le nom de variable, _ agit comme un attrape-tout et garantit que le sujet sera toujours apparié. L'utilisation de _ est optionnelle.

Vous pouvez combiner plusieurs littéraux dans un seul filtre en utilisant | (qui se lit « ou ») :

case 401 | 403 | 404:
    return "Not allowed"
Comportement sans l'attrape-tout

Modifions l'exemple ci-haut en enlevant le dernier bloc case. Il devient :

def http_error(status):
    match status:
        case 400:
            return "Bad request"
        case 404:
            return "Not found"
        case 418:
            return "I'm a teapot"

Sans l'utilisation de _ dans une instruction case, il est possible de ne pas avoir d'appariement. Dans ce cas, il ne se passe rien. Par exemple, si 500 est passé à status, aucune opération n'est effectuée.

Filtres avec un littéral et une variable

Les motifs des filtres peuvent prendre une forme similaire aux affectations multiples et un filtre peut être utilisé pour lier plus d'une variable. Dans cet exemple, un point peut être dissocié entre son abscisse et son ordonnée :

# point is an (x, y) tuple
match point:
    case (0, 0):
        print("Origin")
    case (0, y):
        print(f"Y={y}")
    case (x, 0):
        print(f"X={x}")
    case (x, y):
        print(f"X={x}, Y={y}")
    case _:
        raise ValueError("Not a point")

Le motif du premier filtre comporte deux littéraux, (0, 0), et peut être vu comme une extension du filtre sur un littéral montré plus haut. Les motifs des deux filtres suivants regroupent un littéral et une variable. De plus, la variable est liée à la valeur provenant du sujet (point). Le motif du quatrième filtre capture deux valeurs, ce qui le rend conceptuellement similaire à l'affectation multiple : (x, y) = point.

Filtres et classes

Si vous utilisez des classes pour structurer vos données, vous pouvez utiliser le nom de la classe suivie d'une liste d'arguments comme motif de filtre. Ceci ressemble à un appel du constructeur. Ce filtre peut capturer les attributs de la classe dans des variables :

class Point:
    x: int
    y: int

def location(point):
    match point:
        case Point(x=0, y=0):
            print("Origin is the point's location.")
        case Point(x=0, y=y):
            print(f"Y={y} and the point is on the y-axis.")
        case Point(x=x, y=0):
            print(f"X={x} and the point is on the x-axis.")
        case Point():
            print("The point is located somewhere else on the plane.")
        case _:
            print("Not a point")
Filtres avec arguments positionnels

Vous pouvez utiliser les arguments positionnels avec un certain nombre de classes natives qui définissent l'ordre de leurs attributs, notamment les classes de données (dataclasses). Vous pouvez aussi spécifier la position des attributs quand ils sont utilisés dans les filtres en définissant l'attribut spécial __match_args__ dans vos classes. Par exemple, le mettre à ("x", "y") rend tous les filtres ci-dessous équivalents (en particulier, tous provoquent la liaison de l'attribut y à la variable var) :

Point(1, var)
Point(1, y=var)
Point(x=1, y=var)
Point(y=var, x=1)

Filtres imbriqués

Les filtres peuvent être imbriqués de façon arbitraire. Par exemple, si nous avons une courte liste de points, elle peut être appariée comme ceci :

match points:
    case []:
        print("No points in the list.")
    case [Point(0, 0)]:
        print("The origin is the only point in the list.")
    case [Point(x, y)]:
        print(f"A single point {x}, {y} is in the list.")
    case [Point(0, y1), Point(0, y2)]:
        print(f"Two points on the Y axis at {y1}, {y2} are in the list.")
    case _:
        print("Something else is found in the list.")

Filtres complexes et attrape-tout

Jusqu'à maintenant, les exemples ont utilisé _ seul dans la dernière instruction case. Un attrape-tout peut être utilisé dans un filtre plus complexe tel que ('error', code, _). Par exemple :

match test_variable:
    case ('warning', code, 40):
        print("A warning has been received.")
    case ('error', code, _):
        print(f"An error {code} occurred.")

Dans l'exemple précédent, test_variable s'apparie à ('error', code, 100) et à ('error', code, 800).

Garde

On peut ajouter une clause if à un filtre, ce qu'on appelle une « garde ». Si la garde s'évalue à faux, match poursuit avec la tentative d'appariement du prochain bloc case. Notez que la capture de valeur se produit avant l'évaluation de la garde :

match point:
    case Point(x, y) if x == y:
        print(f"The point is located on the diagonal Y=X at {x}.")
    case Point(x, y):
        print(f"Point is not on the diagonal.")

Autres fonctionnalités importantes

Plusieurs autres fonctionnalités importantes :

  • Comme dans les affectations multiples, les motifs de filtres qui sont des n-uplets ou des listes sont totalement équivalents et autorisent tous les types de séquences. Techniquement, le sujet doit être une séquence. Ainsi, exception importante, les filtres n'autorisent pas les itérateurs. Aussi, pour prémunir d'une erreur commune, les filtres de séquences n'autorisent pas les chaînes ;

  • les filtres de séquence peuvent faire intervenir l'affectation étoilée : [x, y, *reste] ou (x, y, *reste) ont le même sens que dans une affectation avec =. Le nom de variable après l'étoile peut aussi être l'attrape-tout _. Ainsi, (x, y, *_) est un motif de filtre qui reconnaît les séquences à deux éléments ou plus, en capturant les deux premiers et en ignorant le reste ;

  • il existe les filtres d'association, qui ressemblent syntaxiquement aux dictionnaires. Par exemple, le filtre {"bande_passante": b, "latence": l} extrait les valeurs des clés "bande_passante" et "latence" dans un dictionnaire. Contrairement aux filtres de séquence, les clés absentes du filtre sont ignorées et le filtre réussit tout de même. L'affectation double-étoilée (**reste) fonctionne aussi (cependant, **_ serait redondant et n'est donc pas permis) ;

  • on peut capturer la valeur d'une partie du motif d'un filtre avec le mot-clé as, par exemple :

    case (Point(x1, y1), Point(x2, y2) as p2): ...

    Ceci lie x1, y1, x2, y2 comme attendu sans la clause as, et lie p2 à l’entièreté du second élément du sujet ;

  • la plupart des littéraux sont comparés par égalité. Néanmoins, les singletons True, False et None sont comparés par identité ;

  • les filtres peuvent contenir des noms qui se réfèrent à des constantes. Ces noms doivent impérativement être qualifiés (contenir au moins un point) pour ne pas être interprétés comme des variables de capture :

    from enum import Enum
class Color(Enum):
    RED = 0
    GREEN = 1
    BLUE = 2

match color:
    case Color.RED:
        print("I see red!")
    case Color.GREEN:
        print("Grass is green")
    case Color.BLUE:
        print("I'm feeling the blues :(")

Pour la spécification complète, voir la PEP 634. La motivation et la justification des choix sont dans la PEP 635, et un tutoriel plus élaboré se trouve dans la PEP 636.

EncodingWarning et option encoding="locale" optionnels

L'encodage par défaut de TextIOWrapper et de open() dépend de la plateforme et des paramètres régionaux. Comme UTF-8 est utilisé sur la plupart des plateformes Unix, ne pas spécifier l'option encoding pour ouvrir des fichiers UTF-8 est une erreur courante. Par exemple :

# BUG: "rb" mode or encoding="utf-8" should be used.
with open("data.json") as f:
    data = json.load(f)

Pour trouver ce type de bogue, un EncodingWarning optionnel a été ajouté. Il est levé quand sys.flags.warn_default_encoding est True et quand l'encodage utilisé est celui défini par les paramètres régionaux.

L'option -X warn_default_encoding et la variable d’environnement PYTHONWARNDEFAULTENCODING ont été ajoutées pour activer cet avertissement.

Voir Text Encoding pour plus d'informations.

Autres changements au langage

  • Le type int a une nouvelle méthode int.bit_count(), qui renvoie le nombre de chiffres uns dans l’expansion binaire d'un entier donné, aussi connue sous le nom de chiffre de population (population count) (contribution de Niklas Fiekas dans bpo-29882).

  • Les vues renvoyées par dict.keys(), dict.values() et dict.items() ont maintenant toutes un attribut mapping qui donne un objet types.MappingProxyType encapsulant le dictionnaire original (contribution de Dennis Sweeney dans bpo-40890).

  • PEP 618 : la fonction zip() a maintenant un argument optionnel strict, utilisé pour demander que tous les itérables soient de même longueur.

  • Les fonctions d'extensions et les fonctions natives qui prennent des arguments entiers n'acceptent plus les Decimal, Fraction et autres objets qui ne peuvent pas être convertis en entiers sans perte de précision (par exemple ceux qui ont une méthode __int__() mais pas une méthode __index__()) (contribution de Serhiy Storchaka dans bpo-37999).

  • Si object.__ipow__() renvoie NotImplemented, l'opérateur va correctement se rabattre sur object.__pow__() et object.__rpow__() tel qu'attendu (contribution d'Alex Shkop dans bpo-38302).

  • Les expressions d'affectations peuvent maintenant être utilisées dans les littéraux d'ensembles, dans les compréhensions d'ensembles et dans les indices de séquences (mais pas dans les tranches).

  • Les fonctions ont un nouvel attribut __builtins__ qui est utilisé pour repérer les symboles natifs quand la fonction est exécutée, plutôt que de regarder dans __globals__['__builtins__']. L'attribut est initialisé à partir de __globals__["__builtins__"] s'il existe, ou des symboles natifs en cours autrement (contribution de Mark Shannon dans bpo-42990).

  • Deux nouvelles fonctions natives – aiter() et anext() – ont été ajoutées pour fournir les équivalents asynchrones de iter() et de next(), respectivement (contribution de Joshua Bronson, Daniel Pope et Justin Wang dans bpo-31861).

  • Les méthodes statiques (@staticmethod) et les méthodes de classes (@classmethod) héritent maintenant des attributs de méthodes (__module__, __name__, __qualname__, __doc__, __annotations__) et ont un nouvel attribut __wrapped__. De plus, les méthodes statiques sont maintenant appelables en tant que fonctions classiques (contribution de Victor Stinner dans bpo-43682).

  • Les annotations des cibles complexes (toutes cibles autre que simple name telles que définies dans la PEP 526) n'ont plus d'effet à l'exécution avec from __future__ import annotations (contribution de Batuhan Taskaya dans bpo-42737).

  • Les objets class et module créent maintenant paresseusement un dictionnaire d'annotations vide sur demande. Les dictionnaires d'annotations sont stockés dans le __dict__ de l'objet pour garder la retro-compatibilité. Cela renforce les bonnes pratiques relatives à __annotations__ ; pour plus d'information, voir Bonnes pratiques concernant les annotations (contribution de Larry Hastings dans bpo-43901).

  • Les annotations qui contiennent yield, yield from, await ou une expression nommée ne sont plus permises sous from __future__ import annotations à cause de leurs effets secondaires (contribution de Batuhan Taskaya dans bpo-42725).

  • L'utilisation de variables non liées, de super() et d'autres expressions qui peuvent changer le traitement de la table des symboles en tant qu'annotation n'ont plus d'effet sous from __future__ import annotations (contribution de Batuhan Taskaya dans bpo-42725).

  • Le hachage des valeurs NaN des types float et decimal.Decimal dépend maintenant de l'identité de l'objet. Préalablement, cette valeur de hachage était toujours 0 alors que les valeurs NaN ne sont pas égales entre elles. Cela pouvait potentiellement entrainer un temps d'exécution quadratique en raison des collisions excessives des valeurs de hachage lors de la création de dictionnaires et d'ensembles qui contiennent plusieurs NaN (contribution de Raymond Hettinger dans bpo-43475).

  • Une SyntaxError (plutôt qu'une NameError) sera levée quand la constante __debug__ est supprimée (contribution de Dong-hee Na dans bpo-45000).

  • Les exceptions SyntaxError ont maintenant des attributs end_lineno et end_offset. La valeur est None quand ils ne peuvent pas être déterminés (contribution de Pablo Galindo dans bpo-43914).

Nouveaux modules

  • Aucun pour le moment.

Modules améliorés

asyncio

Ajout de la méthode connect_accepted_socket() manquante (contribution d'Alex Grönholm dans bpo-41332).

argparse

L'expression "optional arguments" qui portait à confusion a été remplacée par "options" dans le message d'aide d'argparse. Certains tests devront être adaptés s'ils dépendent d'une comparaison exacte dans la sortie d'aide (contribution de Raymond Hettinger dans bpo-9694).

array

La méthode index() de la classe array.array a maintenant les paramètres optionnels start et stop (contribution d'Anders Lorentsen et de Zackery Spytz dans bpo-31956).

asynchat, asyncore, smtpd

Ces modules ont étés déclarés obsolètes dans leur documentation de modules depuis Python 3.6. Un DeprecationWarning au moment de l'importation est maintenant ajouté pour ces trois modules.

base64

Ajout de base64.b32hexencode() et de base64.b32hexdecode() pour prendre en charge l'encodage Base32 avec l'alphabet hexadécimal étendu.

bdb

Ajout de clearBreakpoints() pour supprimer tous les points d'arrêt (contribution d'Irit Katriel dans bpo-24160).

bisect

Ajout de la possibilité de fournir une fonction key aux API dans le module bisect (contribution de Raymond Hettinger dans bpo-4356).

codecs

Ajout d'une fonction codecs.unregister() pour désinscrire une fonction de recherche de codecs (contribution de Hai Shi dans bpo-41842).

collections.abc

L'attribut __args__ des génériques paramétrables de collections.abc.Callable est maintenant cohérent avec typing.Callable. Les génériques de collections.abc.Callable aplatissent maintenant les types des paramètres à l'instar de typing.Callable. Ceci veut dire que collections.abc.Callable[[int, str], str] aura un attribut __args__ de valeur (int, str, str) ; auparavant, il aurait été ([int, str], str). Pour permettre ce changement, types.GenericAlias peut être dérivée, et une sous-classe sera renvoyée lors de la surcharge du type collections.abc.Callable. Prenez note que TypeError sera levée pour des formes invalides de paramétrisation de collections.abc.Callable, ce qui aurait pu passer silencieusement dans Python 3.9 (contribution de Ken Jin dans bpo-42195).

contextlib

Ajout d'un gestionnaire de contexte contextlib.aclosing() pour fermer de façon sécurisée les générateurs asynchrones et les objets représentants des ressources libérées de façon asynchrone (contribution de Joongi Kim et John Belmonte dans bpo-41229).

Ajout d'un gestionnaire de contexte pour prendre en charge contextlib.nullcontext() (contribution de Tom Gringauz dans bpo-41543).

Ajout de AsyncContextDecorator pour prendre en charge les gestionnaires de contexte asynchrones en tant que décorateurs.

curses

Les fonctions de couleurs étendues ajoutées dans ncurses 6.1 sont utilisées de façon transparente par curses.color_content(), curses.init_color(), curses.init_pair() et curses.pair_content(). Une nouvelle fonction, curses.has_extended_color_support(), indique si la prise en charge des couleurs étendues est fournie par la bibliothèque ncurses sous-jacente (contribution de Jeffrey Kintscher et de Hans Petter Jansson dans bpo-36982).

Les constantes BUTTON5_* sont maintenant exposées dans le module curses si elles sont fournies par la bibliothèque curses sous-jacente (contribution de Zackery Spytz dans bpo-39273).

dataclasses

__slots__

Ajout du paramètre slots dans le décorateur dataclasses.dataclass() (contribution de Yurii Karabas dans bpo-42269).

Champs obligatoirement nommés

Les classes de données (dataclass) prennent maintenant en charge les champs obligatoirement nommés dans la méthode __init__ générée. Il y a plusieurs façons de spécifier les champs obligatoirement nommés.

Vous pouvez indiquer que tous les champs sont obligatoirement nommés :

from dataclasses import dataclass

@dataclass(kw_only=True)
class Birthday:
    name: str
    birthday: datetime.date

Les paramètres name et birthday sont tous deux obligatoirement nommés dans la méthode __init__ générée.

Pour chaque champ, vous pouvez indiquer s'il est obligatoirement nommé :

from dataclasses import dataclass

@dataclass
class Birthday:
    name: str
    birthday: datetime.date = field(kw_only=True)

Ici, seulement birthday est obligatoirement nommé. Si vous assignez kw_only sur un champ particulier, notez qu'il y a des règles concernant l'ordre des champs puisque les champs obligatoirement nommés doivent suivre les champs optionnellement nommés. Voir la documentation de dataclass pour plus de détails.

Vous pouvez aussi indiquer que tous les champs qui suivent un marqueur KW_ONLY sont obligatoirement nommés. Ceci sera probablement l'utilisation la plus commune :

from dataclasses import dataclass, KW_ONLY

@dataclass
class Point:
    x: float
    y: float
    _: KW_ONLY
    z: float = 0.0
    t: float = 0.0

Ici, z et t sont obligatoirement nommés, alors que x et y ne le sont pas (contribution d'Eric V. Smith dans bpo-43532).

distutils

Le paquet distutil est entièrement obsolète et sera retiré dans Python 3.12. Ses fonctionnalités pour spécifier la construction de paquets sont déjà complètement remplacées par les paquets tierce-parties setuptools et packaging. Les autres API régulièrement utilisées sont disponibles ailleurs dans la bibliothèque standard (tel que dans platform, shutil, subprocess ou sysconfig). Il n'est pas prévu de migrer d'autres fonctionnalités de distutils, aussi les applications qui utilisent d'autres fonctions du module doivent faire des copies privées du code. Voir la discussion dans la PEP 632.

La commande bdist_wininst qui est obsolète depuis Python 3.8 a été retirée. La commande bdist_wheel est maintenant recommandée pour distribuer des paquets binaires sous Windows (contribution de Victor Stinner dans bpo-42802).

doctest

Quand un module ne définit pas __loader__, __spec__.loader est utilisé (contribution de Brett Cannon dans bpo-42133).

encodings

La fonction encodings.normalize_encoding() ignore maintenant les caractères non ASCII (contribution de Hai Shi dans bpo-39337).

fileinput

Ajout des paramètres encoding et errors dans fileinput.input() et dans fileinput.FileInput (contribution d'Inada Naoki dans bpo-43712).

fileinput.hook_compressed() renvoie maintenant un objet TextIOWrapper quand mode est "r" et que le fichier est compressé, comme pour les fichiers non compressés (contribution d'Inada Naoki dans bpo-5758).

faulthandler

Le module faulthandler détecte maintenant si une erreur fatale s'est produite pendant un passage du ramasse-miettes (contribution de Victor Stinner dans bpo-44466).

gc

Ajout de fonctions de rappels d'audit pour gc.get_objects(), gc.get_referrers() et gc.get_referents() (contribution de Pablo Galindo dans bpo-43439).

glob

Ajout des paramètres root_dir et dir_fd dans glob() et dans iglob() pour permettre la spécification du répertoire racine utilisé pour la recherche (contribution de Serhiy Storchaka dans bpo-38144).

hashlib

La version minimale d'OpenSSL pour le module hashlib est maintenant 1.1.1 (contribution de Christian Heimes dans PEP 644 et dans bpo-43669).

Le module hashlib offre une prise en charge préliminaire pour OpenSSL 3.0.0 (contribution de Christian Heimes dans bpo-38820 et autres tickets).

Le repli vers la version en pur Python de pbkdf2_hmac() est obsolète. Dorénavant, PBKDF2-HMAC n'est disponible que si Python a été compilé avec la prise en charge d'OpenSSL (contribution de Christian Heimes dans bpo-43880).

hmac

L'implémentation interne du module hmac utilise maintenant HMAC d'OpenSSL (contribution de Christian Heimes dans bpo-40645).

IDLE et idlelib

IDLE invoque maintenant sys.excepthook() (lorsque lancé sans '-n'). Auparavant, les fonctions de rappel définies par l'utilisateur étaient ignorées (contribution par Ken Hilton dans bpo-43008).

Rearrange the settings dialog. Split the General tab into Windows and Shell/Ed tabs. Move help sources, which extend the Help menu, to the Extensions tab. Make space for new options and shorten the dialog. The latter makes the dialog better fit small screens. (Contributed by Terry Jan Reedy in bpo-40468.) Move the indent space setting from the Font tab to the new Windows tab. (Contributed by Mark Roseman and Terry Jan Reedy in bpo-33962.)

Les changements ci-dessus ont été rétro-portés dans le cadre de la maintenance de 3.9.

Ajout d'une barre de côté à la console. Déplacement de l'invite de commande principale (>>>) vers cette barre. Ajout des invites secondaires (...) à la barre de côté. Le clic de gauche et le glisser optionnel sélectionnent une ou plusieurs lignes de texte, tout comme dans la barre de numéros de ligne de la fenêtre d'édition. Le clic droit après la sélection de lignes de texte affiche un menu contextuel pour copier avec invites ('copy with prompts'). Ceci combine les invites de la barre de côté avec le texte sélectionné. Cette option apparait aussi dans le menu contextuel pour le texte (contribution de Tal Einat dans bpo-37903).

Utilisation d'espaces plutôt que des tabulations pour indenter le code interactif. Ceci donne au code interactif la « bonne apparence ». Cette fonctionnalité est fortement corrélée à l'ajout de la barre de côté de la console (contribution de Terry Jan Reedy dans bpo-37892).

Coloration des nouveaux mots clés ad-hoc match, case et _ dans les instructions de filtrage par motifs (pattern matching). Par contre, cette coloration n'est pas parfaite et elle sera incorrecte dans quelques rares cas, y-compris certains _ dans des instructions case (contribution de Tal Einat dans bpo-44010).

Nouveau dans les versions de maintenance 3.10.

Apply syntax highlighting to .pyi files. (Contributed by Alex Waygood and Terry Jan Reedy in bpo-45447.)

importlib.metadata

Équivalence de fonctionnalités avec importlib_metadata 4.6 (historique).

Les points d'entrée de importlib.metadata offrent maintenant une interface plus agréable pour choisir les points d'entrée par groupe et par nom par l'intermédiaire d'une nouvelle classe importlib.metadata.EntryPoints. Voir la rubrique Note sur la Compatibilité (Compatibility Note) dans la documentation du module importlib.metadata pour plus d'information sur son utilisation et ce qui devient obsolète.

Ajout de importlib.metadata.packages_distributions() pour résoudre les modules et paquets Python du niveau racine vers leur importlib.metadata.Distribution.

inspect

Quand un module ne définit pas __loader__, __spec__.loader est utilisé (contribution de Brett Cannon dans bpo-42133).

Ajout de inspect.get_annotations() qui calcule les annotations définies sur un objet de façon sécuritaire. Elle contourne les difficultés d’accéder aux annotations de différents types d'objets et présume très peu de l'objet examiné. inspect.get_annotations() peut également convertir pour vous les annotations contenues dans des chaînes de caractères en objets. inspect.get_annotations() est maintenant considérée comme la meilleure pratique pour accéder au dictionnaire d'annotations de tout objet qui prend en charge les annotations ; pour d'autre information sur les meilleures pratiques relatives aux annotations, voir Bonnes pratiques concernant les annotations. Dans le même esprit, inspect.signature(), inspect.Signature.from_callable() et inspect.Signature.from_function() appellent maintenant inspect.get_annotations() pour récupérer les annotations. Ceci veut dire que inspect.signature() et inspect.Signature.from_callable() peuvent maintenant convertir pour vous les annotations contenues dans des chaînes de caractères en objets (contribution de Larry Hastings dans bpo-43817).

itertools

Add itertools.pairwise(). (Contributed by Raymond Hettinger in bpo-38200.)

linecache

Quand un module ne définit pas __loader__, __spec__.loader est utilisé (contribution de Brett Cannon dans bpo-42133).

os

Ajout de la prise en charge de VxWorks RTOS dans os.cpu_count() (contribution de Peixing Xin dans bpo-41440).

Ajout d'une nouvelle fonction os.eventfd() et des fonctions utilitaires associées pour encapsuler l'appel système eventfd2 sur Linux (contribution de Christian Heimes dans bpo-41001).

Ajout de os.splice() qui permet de déplacer des données entre deux descripteurs de fichiers sans copie entre les espaces noyau et utilisateur. Un des descripteurs de fichiers doit référencer un tube (pipe) (contribution de Pablo Galindo dans bpo-41625).

Ajout de O_EVTONLY, O_FSYNC, O_SYMLINK et O_NOFOLLOW_ANY sur macOS (contribution de Dong-hee Na dans bpo-43106).

os.path

os.path.realpath() accepte maintenant l'argument nommé strict. Lorsqu'il est True, une OSError est levée si le chemin n'existe pas ou si une boucle de liens symboliques est rencontrée (contribution de Barney Gale dans bpo-43757).

pathlib

Ajout de la prise en charge des tranches dans PurePath.parents (contribution de Joshua Cannon dans bpo-35498).

Ajout de la prise en charge de l'indiçage négatif dans PurePath.parents (contribution de Yaroslav Pankovych dans bpo-21041).

Ajout de la méthode Path.hardlink_to qui remplace link_to(). L'ordre des arguments de la nouvelle méthode est le même que symlink_to() (contribution de Barney Gale dans bpo-39950).

pathlib.Path.stat() et chmod() acceptent maintenant l'argument nommé follow_symlinks pour rester cohérent avec les fonctions correspondantes dans le module os (contribution de Barney Gale dans bpo-39906).

platform

Ajout de platform.freedesktop_os_release() pour récupérer l'information d'identification du système d'exploitation selon le fichier standard des versions de systèmes d'exploitations de freedesktop.org (contribution de Christian Heimes dans bpo-28468).

pprint

pprint.pprint() accepte maintenant le nouvel argument nommé underscore_numbers (contribution de sblondon dans bpo-42914).

pprint peut maintenant afficher élégamment les instances de dataclasses.dataclass (contribution de Lewis Gaul dans bpo-43080).

py_compile

Ajout de l'option de ligne de commande --quiet à l'interface de py_compile (contribution de Gregory Schevchenko dans bpo-38731).

pyclbr

Ajout d'un attribut end_lineno aux objets Function et Class dans l'arbre renvoyé par pyclbr.readline() et pyclbr.readline_ex(). Il complète l'attribut lineno déjà existant (contribution d'Aviral Srivastava dans bpo-38307).

shelve

Le module shelve utilise maintenant pickle.DEFAULT_PROTOCOL par défaut plutôt que le protocole 3 du module pickle à la création des objets shelf (contribution de Zackery Spytz dans bpo-34204).

statistics

Ajout des fonctions covariance(), correlation() (corrélation de Pearson) et linear_regression() (régression linéaire simple) (contribution de Tymoteusz Wołodźko dans bpo-38490).

site

Quand un module ne définit pas __loader__, __spec__.loader est utilisé (contribution de Brett Cannon dans bpo-42133).

socket

L'exception socket.timeout est maintenant un alias de TimeoutError (contribution de Christian Heimes dans bpo-42413).

Ajout d'une option pour créer des connecteurs (socket) MPTCP avec IPPROTO_MPTCP (contribution de Rui Cunha dans bpo-43571).

Ajout de l'option IP_RECVTOS pour récupérer la valeur des champs type of service (ToS) ou differentiated services code point (DSCP/ECN) (contribution de Georg Sauthoff dans bpo-44077).

ssl

La version minimale d'OpenSSL pour le module ssl est maintenant 1.1.1 (contribution de Christian Heimes dans PEP 644 et dans bpo-43669).

Le module ssl offre une prise en charge préliminaire pour OpenSSL 3.0.0 et la nouvelle option OP_IGNORE_UNEXPECTED_EOF (contribution de Christian Heimes dans bpo-38820, bpo-43794, bpo-43788, bpo-43791, bpo-43799, bpo-43920, bpo-43789 et bpo-43811).

Les fonctions obsolètes et l'accès aux constantes obsolètes lèvent maintenant un DeprecationWarning. ssl.SSLContext.options a options OP_NO_SSLv2 et OP_NO_SSLv3 définies par défaut ; par conséquent, il ne peut pas avertir si l'option est définie de nouveau. La section obsolescence contient la liste des fonctionnalités obsolètes (contribution de Christian Heimes dans bpo-43880).

La configuration du module ssl est plus sécuritaire par défaut. Les algorithmes de chiffrement sans confidentialité persistante (forward secrecy) et le code d'authentification de message (MAC) SHA-1 sont désactivés par défaut. Le niveau 2 de sécurité ne permet pas les clés faibles de moins de 112 bits pour RSA, DH et ECC. La version minimale du protocole TLS pour SSLContext est 1.2. La configuration est basée sur la recherche de Hynek Schlawack (contribution de Christian Heimes dans bpo-43998).

Les protocoles obsolètes SSL 3.0, TLS 1.0 et TLS 1.1 ne sont plus officiellement pris en charge. Python ne les bloque pas activement, mais les options de compilation d'OpenSSL, les configurations du système d'exploitation, les rustines des fabricants et les suites d'algorithmes de chiffrement peuvent empêcher l’établissement d'une connexion.

Ajout d'un paramètre timeout à la fonction ssl.get_server_certificate() (contribution de Zackery Spytz dans bpo-31870).

Le module ssl utilise les types du tas et l'initialisation multi-phase (contribution de Christian Heimes dans bpo-42333).

Ajout d'un nouveau drapeau de vérification VERIFY_X509_PARTIAL_CHAIN (contribution de l0x dans bpo-40849).

sqlite3

Ajout d'événements d'audit pour connect/handle(), enable_load_extension() et load_extension() (contribution d'Erlend E. Aasland dans bpo-43762).

sys

Ajout de l'attribut sys.orig_argv : la liste des arguments de ligne de commande originalement passée à l'exécutable Python (contribution de Victor Stinner dans bpo-23427).

Ajout de sys.stdlib_module_names qui contient la liste des noms des modules de la bibliothèque standard (contribution de Victor Stinner dans bpo-42955).

_thread

_thread.interrupt_main() prend maintenant l'argument optionnel signum : le numéro de signal à simuler (la valeur par défaut est toujours signal.SIGINT) (contribution d'Antoine Pitrou dans bpo-43356).

threading

Ajout des fonctions threading.gettrace() et threading.getprofile() pour récupérer les fonctions assignées par threading.settrace() et threading.setprofile() respectivement (contribution de Mario Corchero dans bpo-42251).

Ajout de threading.__excepthook__ pour permettre la récupération de threading.excepthook() au cas où elle serait affectée à une valeur incorrecte ou différente (contribution de Mario Corchero dans bpo-42308).

traceback

Les fonctions format_exception(), format_exception_only() et print_exception() peuvent maintenant prendre un objet exception en argument positionnel (contribution de Zackery Spytz et Matthias Bussonnier dans bpo-26389).

types

Les classes types.EllipsisType, types.NoneType et types.NotImplementedType sont ajoutées de nouveau. Elles fournissent un nouvel ensemble de types facilement interprétable par les vérificateurs de types (contribution de Bas van Beek dans bpo-41810).

typing

Pour les changements majeurs, voir Nouvelles fonctionnalités reliées aux indications de types.

Le comportement de typing.Literal a été changé pour être conforme avec la PEP 586 et pour correspondre au comportement des vérificateurs de types statiques défini dans la PEP.

  1. Literal dé-duplique maintenant les paramètres.

  2. La comparaison d'égalité entre objets Literal ne tient plus compte de l'ordre.

  3. Les comparaisons de Literal respectent maintenant les types. Par exemple, Literal[0] == Literal[False] était préalablement évaluée à True. Elle est maintenant False. Pour prendre en charge ce changement, le cache des types de l'implémentation interne peut maintenant différencier entre les types.

  4. Les objets Literal lèvent maintenant une exception TypeError pendant la comparaison d'égalité si au moins un de leurs paramètres n'est pas hachable. Notez que déclarer un Literal avec des paramètres non hachables ne lève pas d'erreur :

    >>> from typing import Literal
>>> Literal[{0}]
>>> Literal[{0}] == Literal[{False}]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'set'

(contribution de Yurii Karabas dans bpo-42345).

Ajout d'une nouvelle fonction typing.is_typeddict() pour inspecter si une annotation est une typing.TypedDict (contribution de Patrick Reader dans bpo-41792).

Les sous-classes de typing.Protocol qui ne contiennent que des déclarations de variables de données vont maintenant lever une TypeError quand elles sont testées avec isinstance, sauf si elles sont décorées par runtime_checkable(). Auparavant, ces tests passaient silencieusement. Les utilisateurs doivent décorer leurs sous-classes avec le décorateur runtime_checkable() s'ils désirent les protocoles à l'exécution (contribution de Yurii Karabas dans bpo-38908).

Importer quoi que ce soit des sous-modules typing.io et typing.re émet maintenant un DeprecationWarning. Ces sous-modules sont obsolètes depuis Python 3.8 et seront retirés dans une version future de Python. Tout ce qui appartient à ces modules doit plutôt être importé directement du module typing (contribution de Sebastian Rittau dans bpo-38291).

unittest

Ajout d'une nouvelle méthode assertNoLogs() pour complémenter la méthode existante assertLogs() (contribution de Kit Yan Choi dans bpo-39385).

urllib.parse

Les versions préalables à Python 3.10 acceptaient les deux caractères ; et & comme séparateurs de paramètres de requêtes dans urllib.parse.parse_qs() et urllib.parse.parse_qsl(). Pour prévenir des failles de sécurité potentielles et pour respecter les dernières recommandations du W3C, ceci a été changé pour ne permettre qu'une seule clé de séparation, avec & par défaut. Ce changement affecte aussi l'implémentation interne de cgi.parse() et de cgi.parse_multipart() puisqu'elles utilisent les fonctions affectées. Pour plus de détails, voir la documentation respective de ces fonctions (contribution d'Adam Goldschmidt, de Senthil Kumaran et de Ken Jin dans bpo-42967).

La présence de caractères de saut de ligne ou de tabulation dans une URL permet certaines formes d'attaques. En conformité avec la spécification du WHATWG qui met à jour la RFC 3986, les caractères ASCII de saut de ligne \n, \r et de tabulation \t sont retirés des URL par l'analyseur dans urllib.parse pour contrer ces attaques. Le jeu de caractères à retirer est contrôlé par une nouvelle variable de module urllib.parse._UNSAFE_URL_BYTES_TO_REMOVE (voir bpo-43882).

xml

Ajout d'une classe LexicalHandler au module xml.sax.handler (contribution de Jonathan Gossage de Zackery Spytz dans bpo-35018).

zipimport

Ajout des méthodes relatives à la PEP 451 : find_spec(), zipimport.zipimporter.create_module() et zipimport.zipimporter.exec_module() (contribution de Brett Cannon dans bpo-42131).

Ajout de la méthode invalidate_caches() (contribution de Desmond Cheong dans bpo-14678).

Optimisations

  • Les constructeurs de str(), bytes() et bytearray() sont maintenant plus rapides (environ 30—40 % pour les petits objets) (contribution de Serhiy Storchaka dans bpo-41334).

  • Le module runpy importe maintenant moins de modules. Le temps de démarrage de la commande python3 -m module-name est en moyenne 1,4 fois plus rapide. Sur Linux python3 -I -m module-name importe 69 modules dans Python 3.9, alors qu'elle n'en importe que 51 (18 de moins) dans Python 3.10 (contribution de Victor Stinner dans bpo-41006 et dans bpo-41718).

  • L'instruction LOAD_ATTR utilise maintenant le mécanisme de cache par code d'opération. Elle est environ 36 % plus rapide pour les attributs ordinaires et 44 % plus rapide pour les slots (contribution de Pablo Galindo et de Yury Selivanov dans bpo-42093 et Guido van Rossum dans bpo-42927, basée sur des idées originalement mises en œuvre dans PyPy et dans MicroPython).

  • Lors de la construction de Python avec --enable-optimizations, -fno-semantic-interposition est maintenant ajouté aux lignes de commande de compilation et d'édition des liens. Ceci accélère les binaires de l'interpréteur Python créés avec --enable-shared et gcc jusqu'à 30 %. Voir cet article (en anglais) pour plus de détails (contribution de Victor Stinner et Pablo Galindo dans bpo-38980).

  • Ré-usinage du code assurant la gestion du tampon de sortie pour les modules bz2, lzma et zlib. Ajout de la fonction .readall() à la classe _compression.DecompressReader. La décompression bz2 est 1,09 à 1,17 fois plus rapide, la décompression lzma est 1,20 à 1,32 fois plus rapide, GzipFile.read(-1) est 1,11 à 1,18 fois plus rapide (contribution de Ma Lin, révision par Gregory P. Smith dans bpo-41486).

  • Quand les annotations sous forme de chaînes sont utilisées, les dictionnaires d'annotations ne sont plus créés à la création de la fonction. À la place, elles sont stockées dans des n-uplets de chaînes et l'objet fonction les convertit vers le dictionnaire d'annotations de façon paresseuse (c.-à-d. au besoin). Cette optimisation réduit de moitié le temps CPU nécessaire à la définition d'une fonction annotée (contribution de Yurii Karabas et Inada Naoki dans bpo-42202).

  • Les fonctions de recherche de sous-chaînes telles que str1 in str2 et str2.find(str1) peuvent utiliser maintenant l'algorithme « bidirectionnel » de recherche de chaînes Crochemore et Perrin pour éviter le comportement quadratique sur les longues chaînes (contribution de Dennis Sweeney dans bpo-41972).

  • Ajout d'une micro-optimisation dans _PyType_Lookup() pour améliorer la performance de la recherche du type des attributs dans le cache, dans le cas le plus commun où il est dans le cache. Ceci accélère l'interpréteur d'un facteur de 1,04 en moyenne (contribution de Dino Viehland dans bpo-43452).

  • Les fonctions natives suivantes prennent maintenant en charge la convention d'appel plus performante vectorcall définie dans la PEP 590 : map(), filter(), reversed(), bool() et float() (contribution de Dong-hee Na et Jeroen Demeyer dans bpo-43575, bpo-43287, bpo-41922, bpo-41873 et bpo-41870).

  • La performance de BZ2File est améliorée par le retrait d'un verrou RLock interne. Ceci rend BZ2File incompatible avec les fils d'exécutions multiples quand il y a plusieurs lecteurs ou écrivains concurrents, tout comme les classes équivalentes dans gzip et lzma qui l'ont toujours été (contribution de Inada Naoki dans bpo-43785).

Obsolescence

Retrait

  • Les méthodes spéciales __int__, __float__, __floordiv__, __mod__, __divmod__, __rfloordiv__, __rmod__ et __rdivmod__ sont retirées de la classe complex. Elles levaient toujours une TypeError (contribution de Serhiy Storchaka dans bpo-41974).

  • La méthode ParserBase.error() du module privé et non-documenté _markupbase a été retirée. html.parser.HTMLParser est la seule sous-classe de ParserBase et son implémentation de la méthode error() a été retirée dans Python 3.5 (contribution de Berker Peksag dans bpo-31844).

  • Retrait de l'attribut unicodedata.ucnhash_CAPI qui était un objet PyCapsule interne. La structure privée associée _PyUnicode_Name_CAPI a été déplacée vers l'API C interne (contribution de Victor Stinner dans bpo-42157).

  • Retrait du module parser qui était obsolète depuis 3.9 étant donné la transition vers le nouvel analyseur syntaxique PEG. Retrait aussi des fichiers source et en-tête C qui n'étaient utilisés que par l'ancien analyseur, ceci comprend node.h, parser.h, graminit.h et grammar.h.

  • Retrait des fonctions PyParser_SimpleParseStringFlags, PyParser_SimpleParseStringFlagsFilename, PyParser_SimpleParseFileFlags et PyNode_Compile de l'API C publique. Elles étaient obsolètes depuis 3.9 étant donné la transition vers l'analyseur syntaxique PEG.

  • Retrait du module formatter qui était obsolète depuis Python 3.4. Il était quelque peu désuet, peu utilisé et non-testé. Il était originalement planifié pour le retrait dans Python 3.6, mais ces retraits ont été retardés jusqu'à la fin de la prise en charge de Python 2.7. Les utilisateurs de ce module doivent copier les classes qu'ils utilisent dans leur propre code (contribution de Dong-hee Na et Terry J. Reedy dans bpo-42299).

  • Retrait de la fonction PyModule_GetWarningsModule() qui était maintenant inutile depuis la conversion de _warnings en module natif dans 2.6 (contribution de Hai Shi dans bpo-42599).

  • Retrait des alias obsolètes Classes de base abstraites de collections du module collections (contribution de Victor Stinner dans bpo-37324).

  • Le paramètre loop a été retiré de la majorité de l'API haut-niveau d'asyncio. Il était obsolète depuis Python 3.8. La motivation pour ce changement avait plusieurs facettes :

    1. ceci simplifie l'API haut-niveau ;

    2. les fonctions dans l'API haut niveau reçoivent implicitement la boucle d'évènements qui tourne dans le présent fil d'exécution depuis Python 3.7. Il n'y a aucun besoin de passer la boucle d'évènements à l'API dans la majorité de son utilisation normale ;

    3. le passage de la boucle d'évènements cause facilement des erreurs quand plusieurs boucles qui tournent dans plusieurs fils d'exécution sont impliquées.

    Prenez note que l'API bas-niveau accepte toujours le paramètre loop. Voir Changements dans l'API Python pour plus d'exemples sur comment remplacer le code existant

    (contribution de Yurii Karabas, Andrew Svetlov, Yury Selivanov et Kyle Stanley dans bpo-42392).

Portage vers Python 3.10

Cette section liste les changements mentionnés préalablement et autres améliorations qui peuvent demander des changements à votre code.

Changements à la syntaxe de Python

  • Un DeprecationWarning est maintenant levé lors de la compilation de syntaxe qui était préalablement valide si un littéral numérique est immédiatement suivi d'un mot clé (comme dans 0in x). Dans une version future, il sera changé en avertissement de syntaxe, puis finalement en erreur de syntaxe. Pour vous débarrasser de l'avertissement et pour rendre votre code compatible avec les versions futures de Python, ajoutez simplement une espace entre le littéral numérique et le mot clé qui le suit (contribution de Serhiy Storchaka dans bpo-43833).

Changements dans l'API Python

  • Les paramètres etype des fonctions format_exception(), format_exception_only() et print_exception() du module traceback ont étés renommés exc (contribution de Zackery Spytz et Matthias Bussonnier dans bpo-26389).

  • atexit : à la fin de l'exécution de Python, si une fonction de rappel qui a été enregistrée avec atexit.register() échoue, son exception est maintenant journalisée. Préalablement, seulement certaines exceptions étaient journalisées et la dernière exception était toujours ignorée de façon silencieuse (contribution de Victor Stinner dans bpo-42639).

  • Les génériques de collections.abc.Callable aplatissent maintenant les paramètres de types tel qu'il est fait par typing.Callable. Ceci veut dire que collections.abc.Callable[[int, str], str] aura un attribut __args__ de valeur (int, str, str) ; préalablement, il aurait été ([int, str], str). Les codes qui accèdent aux arguments par typing.get_args() ou __args__ doivent tenir compte de ce changement. De plus, TypeError sera levée pour des formes invalides de paramétrisation de collections.abc.Callable, ce qui aurait pu passer silencieusement dans Python 3.9 (contribution de Ken Jin dans bpo-42195).

  • socket.htons() et socket.ntohs() lèvent maintenant OverflowError plutôt que DeprecationWarning si le paramètre passé est trop grand pour être stocké dans un entier 16-bit non-signé (contribution de Erlend E. Aasland dans bpo-42393).

  • Le paramètre loop a été retiré de la majorité de l'API haut-niveau d'asyncio suite à la déclaration de son obsolescence dans Python 3.8.

    Une coroutine qui ressemble actuellement à ceci :

    async def foo(loop):
    await asyncio.sleep(1, loop=loop)

    Doit être remplacée par ceci :

    async def foo():
    await asyncio.sleep(1)

    Si foo() a été spécifiquement conçue pour ne pas s'exécuter dans le fil d'exécution courant, (par exemple pour tourner dans la boucle d'exécution d'un autre fil), l'utilisation de asyncio.run_coroutine_threadsafe() est probablement plus appropriée.

    (contribution de Yurii Karabas, Andrew Svetlov, Yury Selivanov et Kyle Stanley dans bpo-42392).

  • Le constructeur de types.FunctionType hérite maintenant des définitions natives si le dictionnaire globals n'a pas de clé "__builtins__", plutôt que d'utiliser {"None": None} pour les définitions natives : même comportement que celui des fonctions eval() et exec(). Définir une fonction avec def function(...): ... en Python n'est pas affecté, les globales ne peuvent pas être changées avec cette syntaxe : elles héritent aussi des définitions natives courantes (contribution de Victor Stinner dans bpo-42990).

Changements dans l'API C

  • Les fonctions de l'API C PyParser_SimpleParseStringFlags, PyParser_SimpleParseStringFlagsFilename, PyParser_SimpleParseFileFlags et PyNode_Compile ainsi que struct _node, le type utilisé par ces fonctions, ont été retirés suite à la transition vers le nouvel analyseur syntaxique PEG.

    Le code source doit maintenant être compilé directement en un objet code, en utilisant par exemple Py_CompileString(). L'objet code ainsi produit peut ensuite être évalué, en utilisant par exemple PyEval_EvalCode().

    Spécifiquement :

    • Un appel à PyParser_SimpleParseStringFlags suivi de PyNode_Compile peut être remplacé par Py_CompileString() ;

    • Il n'y a pas de remplacement immédiat pour PyParser_SimpleParseFileFlags. Pour compiler du code à partir d'un argument FILE *, vous devez lire le fichier en C et passer le tampon résultant à Py_CompileString().

    • Pour compiler un fichier à partir du char * de son nom, ouvrez le fichier de façon explicite, lisez son contenu et compilez le résultat. Une façon de faire est d'utiliser le module io en conjonction avec PyImport_ImportModule(), PyObject_CallMethod(), PyBytes_AsString() et Py_CompileString(), comme dans l'esquisse qui suit (les déclarations et la gestion d'erreurs ne sont pas incluses) :

      io_module = Import_ImportModule("io");
fileobject = PyObject_CallMethod(io_module, "open", "ss", filename, "rb");
source_bytes_object = PyObject_CallMethod(fileobject, "read", "");
result = PyObject_CallMethod(fileobject, "close", "");
source_buf = PyBytes_AsString(source_bytes_object);
code = Py_CompileString(source_buf, filename, Py_file_input);

    • Pour les objets FrameObject, le champ f_lasti représente maintenant en décalage par wordcode plutôt qu'un simple décalage dans la chaîne de code intermédiaire. Il est donc nécessaire de multiplier ce nombre par 2 pour l'utiliser dans les API qui attendent un décalage par octet (tel que PyCode_Addr2Line(), par exemple). Prenez aussi note que le champ f_lasti de FrameObject n'est pas considéré stable : utilisez plutôt PyFrame_GetLineNumber().

Changements au code intermédiaire CPython

  • L'instruction MAKE_FUNCTION accepte maintenant soit un dictionnaire, soit un n-uplet de chaînes pour l'annotation de la fonction (contribution de Yurii Karabas et Inada Naoki dans bpo-42202).

Changements à la compilation

  • PEP 644 : la version minimale d'OpenSSL pour Python est maintenant 1.1.1. OpenSSL 1.0.2 n'est plus prise en charge (contribution de Christian Heimes dans bpo-43669).

  • Les fonctions de C99 snprintf() et vsnprintf() sont maintenant nécessaires à la compilation de Python (contribution de Victor Stinner dans bpo-36020).

  • La version minimale de SQLite pour le module sqlite3 est maintenant 3.7.15 (contribution de Sergey Fedoseev et Erlend E. Aasland dans bpo-40744 et bpo-40810).

  • Le module atexit doit maintenant toujours être compilé en tant que module natif (contribution de Victor Stinner dans bpo-42639).

  • Ajout de l'option --disable-test-modules au script configure : ne pas compiler ni installer les modules de tests (contribution de Xavier de Gaye, Thomas Petazzoni et Peixing Xin dans bpo-27640).

  • Ajout de l'option --with-wheel-pkg-dir=PATH au script ./configure. Si elle est passée, le module ensurepip recherche les paquets wheel de setuptools et de pip dans ce répertoire : si les deux sont présents, ces paquets wheel sont utilisés plutôt que ceux inclus avec ensurepip.

    La politique de paquets de certaines distributions Linux déconseille l'inclusion des dépendances. Par exemple, Fedora installe les paquets wheel dans le répertoire /usr/share/python-wheels/ et n'installe pas le paquet ensurepip._bundled

    (contribution de Victor Stinner dans bpo-42856).

  • Ajout d'une nouvelle option --without-static-libpython au script configure pour ne pas compiler la bibliothèque statique libpythonMAJOR.MINOR.a et ne pas installer le fichier objet python.o

    (contribution de Victor Stinner dans bpo-43103).

  • Le script configure utilise maintenant l'utilitaire pkg-config lorsqu'il est disponible pour repérer l'emplacement des en-têtes et des bibliothèques Tcl/Tk. Comme auparavant, ces emplacements peuvent être spécifiés de façon explicite par les options de configuration --with-tcltk-includes et --with-tcltk-libs (contribution de Manolis Stamatogiannakis et bpo-42603).

  • Ajout de l'option --with-openssl-rpath au script configure. Cette option simplifie la compilation de Python avec une installation personnalisée d'OpenSSL, par exemple : ./configure --with-openssl=/path/to/openssl --with-openssl-rpath=auto (contribution de Christian Heimes dans bpo-43466).

Changements à l'API C

PEP 652 : maintenance d'une ABI stable

L'interface binaire-programme (Application Binary Interface, ABI en anglais) stable pour les modules d'extension ou pour l'intégration de Python est maintenant définie de façon explicite. Le document C API Stability décrit les garanties de stabilité pour l'API C et pour l'interface binaire-programme ainsi que les bonnes pratiques pour travailler avec l'interface binaire-programme stable

(contribution de Petr Viktorin dans PEP 652 et dans bpo-43795).

Nouvelles fonctionnalités

  • Le résultat de PyNumber_Index() est maintenant exactement de type int. Auparavant, le résultat pouvait être une instance d'une classe dérivée de int (contribution de Serhiy Storchaka dans bpo-40792).

  • Ajout d'un nouveau champ orig_argv à la structure PyConfig : la liste des arguments de ligne de commande originalement passée à l'exécutable Python (contribution de Victor Stinner dans bpo-23427).

  • Les macros PyDateTime_DATE_GET_TZINFO() et PyDateTime_TIME_GET_TZINFO() ont été ajoutées pour récupérer l'attribut tzinfo des objets datetime.datetime et datetime.time (contribution de Zackery Spytz dans bpo-30155).

  • Ajout d'une fonction PyCodec_Unregister() pour désinscrire une fonction de recherche de codecs (contribution de Hai Shi dans bpo-41842).

  • Ajout de la fonction PyIter_Send() pour acheminer une valeur dans un itérateur sans lever une exception StopIteration (contribution de Vladimir Matveev dans bpo-41756).

  • Ajout de PyUnicode_AsUTF8AndSize() à l'API C limitée (contribution d'Alex Gaynor dans bpo-41784).

  • Ajout de la fonction PyModule_AddObjectRef() : comparable à PyModule_AddObject() mais ne s’accapare pas une référence à la valeur s'il y a réussite (contribution de Victor Stinner dans bpo-1635741).

  • Ajout des fonctions Py_NewRef() et Py_XNewRef() pour incrémenter le compteur des références d'un objet et renvoyer l'objet (contribution de Victor Stinner dans bpo-42262).

  • Les fonctions PyType_FromSpecWithBases() et PyType_FromModuleAndSpec() n'acceptent maintenant qu'une seule classe pour l'argument bases (contribution Serhiy Storchaka dans bpo-42423).

  • La fonction PyType_FromModuleAndSpec() accepte maintenant NULL dans l'emplacement tp_doc (contribution de Hai Shi dans bpo-41832).

  • La fonction PyType_GetSlot() peut maintenant accepter des types statiques (contribution de Hai Shi et Petr Viktorin dans bpo-41073).

  • Ajout d'une nouvelle fonction PySet_CheckExact() à l'API C pour vérifier si un objet est une instance de set mais pas une instance d'un sous-type (contribution de Pablo Galindo dans bpo-43277).

  • Ajout de PyErr_SetInterruptEx() qui accepte le numéro d'un signal à simuler (contribution d'Antoine Pitrou dans bpo-43356).

  • L'API C limitée est maintenant prise en charge si Python est compilé en mode débogage (si la macro Py_DEBUG est définie). Dans l'API C limitée, les fonctions Py_INCREF() et Py_DECREF() sont maintenant implémentées en appel de fonctions opaques, plutôt que d'accéder directement au champ PyObject.ob_refcnt. C'est le cas si Python est compilé en mode débogage et que la macro Py_LIMITED_API vise Python 3.10 ou plus récent. Il est possible de prendre en charge l'API C limitée en mode débogage, car la structure PyObject est la même dans les versions standard et dans les versions débogage depuis Python 3.8 (voir bpo-36465).

    L'API C limitée n'est toujours pas prise en charge dans les compilations spéciales avec l'option --with-trace-refs (macro Py_TRACE_REFS) (Contribution de Victor Stinner dans bpo-43688).

  • Ajout de la fonction Py_Is(x, y) pour vérifier si l'objet x est l'objet y, tout comme x is y en Python. Ajout aussi des fonctions Py_IsNone(), Py_IsTrue() et Py_IsFalse() pour vérifier si l'objet est le singleton None, le singleton True ou le singleton False, respectivement (contribution de Victor Stinner dans bpo-43753).

  • Ajout de fonctions pour contrôler le ramasse-miettes en C : PyGC_Enable(), PyGC_Disable() et PyGC_IsEnabled(). Ces fonctions permettent d'activer, de désactiver et d'interroger l'état du ramasse-miettes dans du code C sans avoir à importer le module gc.

  • Ajout d'une nouvelle option Py_TPFLAGS_DISALLOW_INSTANTIATION pour les types. Elle empêche la création d'instances de ce type (contribution de Victor Stinner dans bpo-43916).

  • Ajout d'une nouvelle option Py_TPFLAGS_IMMUTABLETYPE pour les types qui permet de créer des objets de types immuable : les attributs du type ne peuvent pas être affectés ou supprimés (contribution de Victor Stinner et d'Erlend E. Aasland dans bpo-43908).

Portage vers Python 3.10

  • The PY_SSIZE_T_CLEAN macro must now be defined to use PyArg_ParseTuple() and Py_BuildValue() formats which use #: es#, et#, s#, u#, y#, z#, U# and Z#. See Parsing arguments and building values and the PEP 353. (Contributed by Victor Stinner in bpo-40943.)

  • Étant donné la conversion de Py_REFCNT() en fonction statique en-ligne, Py_REFCNT(obj) = new_refcnt doit être remplacé par Py_SET_REFCNT(obj, new_refcnt) : voir Py_SET_REFCNT() (disponible depuis Python 3.9). Pour la rétro-compatibilité, cette macro peut être utilisée :

    #if PY_VERSION_HEX < 0x030900A4
#  define Py_SET_REFCNT(obj, refcnt) ((Py_REFCNT(obj) = (refcnt)), (void)0)
#endif

    (contribution de Victor Stinner dans bpo-39573).

  • Appeler PyDict_GetItem() sans avoir obtenu le GIL était autorisé pour des raisons historiques. Ceci n'est plus permis (contribution de Victor Stinner dans bpo-40839).

  • PyUnicode_FromUnicode(NULL, size) et PyUnicode_FromStringAndSize(NULL, size) lèvent maintenant un DeprecationWarning. Vous devez utiliser PyUnicode_New() pour allouer un objet Unicode sans donnée initiale (contribution de Inada Naoki dans bpo-36346).

  • La structure privée _PyUnicode_Name_CAPI``de l'API PyCapsule ``unicodedata.ucnhash_CAPI a été déplacée dans l'API C interne. (Contribution par Victor Stinner dans bpo-42157.)

  • Py_GetPath(), Py_GetPrefix(), Py_GetExecPrefix(), Py_GetProgramFullPath(), Py_GetPythonHome() and Py_GetProgramName() functions now return NULL if called before Py_Initialize() (before Python is initialized). Use the new Python Initialization Configuration API to get the Python Path Configuration.. (Contributed by Victor Stinner in bpo-42260.)

  • PyList_SET_ITEM(), PyTuple_SET_ITEM() and PyCell_SET() macros can no longer be used as l-value or r-value. For example, x = PyList_SET_ITEM(a, b, c) and PyList_SET_ITEM(a, b, c) = x now fail with a compiler error. It prevents bugs like if (PyList_SET_ITEM (a, b, c) < 0) ... test. (Contributed by Zackery Spytz and Victor Stinner in bpo-30459.)

  • The non-limited API files odictobject.h, parser_interface.h, picklebufobject.h, pyarena.h, pyctype.h, pydebug.h, pyfpe.h, and pytime.h have been moved to the Include/cpython directory. These files must not be included directly, as they are already included in Python.h: Include Files. If they have been included directly, consider including Python.h instead. (Contributed by Nicholas Sim in bpo-35134)

  • Use the Py_TPFLAGS_IMMUTABLETYPE type flag to create immutable type objects. Do not rely on Py_TPFLAGS_HEAPTYPE to decide if a type object is mutable or not; check if Py_TPFLAGS_IMMUTABLETYPE is set instead. (Contributed by Victor Stinner and Erlend E. Aasland in bpo-43908.)

  • La fonction non-documentée Py_FrozenMain a été retirée de l'API limitée. La fonction est principalement utile pour les compilations personnalisées de Python (contribution de Petr Viktorin dans bpo-26241).

Obsolescence

  • La fonction PyUnicode_InternImmortal() est maintenant obsolète et sera retirée dans Python 3.12 : utilisez plutôt PyUnicode_InternInPlace() (contribution de Victor Stinner dans bpo-41692).

Retrait

  • Retrait des fonctions Py_UNICODE_str* manipulant des chaînes Py_UNICODE* (contribution de Inada Naoki dans bpo-41123) :

  • Retrait de PyUnicode_GetMax(). Vous devez migrer vers les nouvelles API de la PEP 393 (contribution de Inada Naoki dans bpo-41103).

  • Retrait de PyLong_FromUnicode(). Vous devez migrer vers PyLong_FromUnicodeObject() (contribution de Inada Naoki dans bpo-41103).

  • Retrait de PyUnicode_AsUnicodeCopy(). Vous devez utiliser PyUnicode_AsUCS4Copy() ou PyUnicode_AsWideCharString() (contribution de Inada Naoki dans bpo-41103).

  • Retrait de la variable _Py_CheckRecursionLimit : elle a été remplacée par le champ ceval.recursion_limit de la structure PyInterpreterState (contribution de Victor Stinner dans bpo-41834).

  • Retrait des macros non-documentées Py_ALLOW_RECURSION et Py_END_ALLOW_RECURSION et du champ recursion_critical de la structure PyInterpreterState (contribution de Serhiy Storchaka dans bpo-41936).

  • Retrait de la fonction non-documentée PyOS_InitInterrupts(). L'initialisation de Python installe déjà les gestionnaires de signaux de façon implicite : voir PyConfig.install_signal_handlers (contribution de Victor Stinner dans bpo-41713).

  • Retrait de la fonction PyAST_Validate(). Il n'est plus possible de construire un objet AST (type mod_ty) avec l'API C publique. La fonction était déjà retirée de l'API C limitée (PEP 384) (contribution de Victor Stinner dans bpo-43244).

  • Retrait du fichier d'en-tête symtable.h et des fonctions non-documentées :

    • PyST_GetScope() ;

    • PySymtable_Build() ;

    • PySymtable_BuildObject() ;

    • PySymtable_Free() ;

    • Py_SymtableString() ;

    • Py_SymtableStringObject().

    Par erreur, la fonction Py_SymtableString() faisait partie de l'ABI stable, mais elle ne pouvait pas être utilisée, car le fichier d'en-tête symtable.h était exclu de l'API C limitée.

    Utilisez plutôt le module Python symtable (contribution de Victor Stinner dans bpo-43244).

  • Retrait de PyOS_ReadlineFunctionPointer() des fichiers d'en-tête de l'API C limitée et de python3.dll, la bibliothèque qui fournit l'ABI stable sur Windows. Étant donné que la fonction prend un FILE* en argument, la stabilité de son interface binaire-programme ne peut pas être garantie (contribution de Petr Viktorin dans bpo-43868).

  • Retrait des fichiers d'en-tête ast.h, asdl.h et Python-ast.h. Ces fonctions étaient non-documentées et exclues de l'API C limitée. La majorité des noms définis dans ces fichiers d'en-tête n'avaient pas le préfixe Py et pouvaient ainsi causer des conflits de noms. Par exemple, Python-ast.h définit une macro Yield qui était en conflit avec le nom Yield utilisé dans le fichier d'en-tête <winbase.h> de Windows. Utilisez plutôt le module Python ast (contribution de Victor Stinner dans bpo-43244).

  • Retrait des fonctions d'analyse syntaxique et de compilation qui utilisent le type struct _mod car l'API C publique pour manipuler les AST a été retirée :

    • PyAST_Compile() ;

    • PyAST_CompileEx() ;

    • PyAST_CompileObject() ;

    • PyFuture_FromAST() ;

    • PyFuture_FromASTObject() ;

    • PyParser_ASTFromFile() ;

    • PyParser_ASTFromFileObject() ;

    • PyParser_ASTFromFilename() ;

    • PyParser_ASTFromString() ;

    • PyParser_ASTFromStringObject().

    Ces fonctions étaient non-documentées et exclues de l'API C limitée (contribution de Victor Stinner dans bpo-43244).

  • Retrait du fichier d'en-tête pyarena.h et des fonctions :

    • PyArena_New() ;

    • PyArena_Free() ;

    • PyArena_Malloc() ;

    • PyArena_AddPyObject().

    Ces fonctions étaient non-documentées et exclues de l'API C limitée ; elles n'étaient utilisées que par le compilateur dans l'implémentation interne (contribution de Victor Stinner dans bpo-43244).

  • Retrait du champ PyThreadState.use_tracing pour optimiser Python (contribution de Mark Shannon dans bpo-43760).