Python 3.15 est sorti : imports paresseux, UTF-8 par défaut et fin de vie de Python 3.10

Python 3.15 est disponible depuis le 9 octobre 2026. Cette version apporte des imports paresseux explicites, un type frozendict intégré et un nouveau profileur, mais elle change aussi un comportement de fond : l’encodage UTF-8 devient la valeur par défaut pour les fichiers ouverts sans paramètre encoding. Dans le même temps, Python 3.10 est arrivé en fin de vie le 1er octobre 2026 : il ne reçoit plus aucun correctif, même de sécurité.

Les nouveautés qui changent le quotidien

Les imports paresseux (PEP 810)

Le mot-clé contextuel lazy permet de déclarer un import qui ne sera réellement exécuté qu’au premier usage du module :

lazy import json
lazy from pathlib import Path

L’intérêt est surtout le temps de démarrage : outils en ligne de commande, scripts lancés par cron, fonctions serverless. Un module lourd importé « au cas où » ne coûte plus rien tant qu’il n’est pas utilisé. Le comportement peut aussi être piloté globalement avec l’option -X lazy_imports, la variable PYTHON_LAZY_IMPORTS ou sys.set_lazy_imports().

Quelques limites : lazy provoque une SyntaxError à l’intérieur d’une fonction, d’une classe ou d’un bloc try, ainsi qu’avec les imports étoilés et les imports __future__.

Un frozendict intégré (PEP 814)

Python dispose enfin d’un dictionnaire immuable natif. Attention, frozendict n’hérite pas de dict : un code qui teste isinstance(x, dict) ne le reconnaîtra pas.

D’autres ajouts notables

• PEP 661 : un type sentinel intégré, pour les valeurs « absentes » distinctes de None.
• PEP 798 : le dépaquetage avec * et ** dans les compréhensions, par exemple [*L for L in lists].
• PEP 799 : un paquet profiling avec profiling.tracing et profiling.sampling, ce dernier étant un profileur par échantillonnage.
• PEP 831 : les frame pointers activés par défaut sur les plateformes compatibles, ce qui facilite le profilage système.
• re.prefixmatch() : nouvel alias explicite, re.match() étant désormais déconseillé « en douceur » (sans retrait programmé).

Les performances

Le compilateur JIT reste expérimental, mais progresse. Selon les notes de version, il est en moyenne 7 à 8 % plus rapide que l’interpréteur standard sur Linux x86-64, et 11 à 12 % plus rapide que l’interpréteur tail-calling sur macOS AArch64. Les écarts selon les programmes sont importants : d’un ralentissement d’environ 15 % à plus du double de vitesse.

Côté bibliothèque standard, l’encodage base64 est environ deux fois plus rapide et le décodage environ trois fois plus rapide. Base32, Ascii85, Base85 et Z85 ont été réécrits en C.

Les ruptures de compatibilité à vérifier

UTF-8 par défaut (PEP 686)

C’est le changement le plus susceptible de surprendre. open() et les autres fonctions d’entrée-sortie utilisent désormais UTF-8 quand aucun encoding n’est précisé. Sur Linux, cela ne change souvent rien. Sur Windows, où l’encodage par défaut dépendait de la configuration régionale, un script qui lisait des CSV exportés en Windows-1252 peut se mettre à afficher des caractères accentués cassés ou lever une erreur.

Deux solutions : passer explicitement encoding="cp1252" (ou "utf-8") dans vos appels, ce que recommande la documentation, ou revenir temporairement à l’ancien comportement avec PYTHONUTF8=0 ou -X utf8=0.

Les retraits

La version supprime plusieurs éléments dépréciés depuis longtemps, notamment :

• les modules sre_compile, sre_constants et sre_parse ;
• CGIHTTPRequestHandler et l’option --cgi de python -m http.server ;
• glob.glob0() et glob.glob1() ;
• PurePath.is_reserved() (remplacé par os.path.isreserved()) ;
• platform.java_ver() ;
• la syntaxe NamedTuple("Point", x=int, y=int) et @typing.no_type_check_decorator ;
• l’attribut de module __cached__ (utilisez __spec__.cached).

Côté C, plusieurs fonctions comme PyWeakref_GetObject() ou Py_GetPath() disparaissent. Les extensions compilées anciennes sont donc à recompiler et parfois à adapter.

D’autres comportements modifiés

• importlib.metadata.metadata() lève maintenant MetadataNotFound au lieu de renvoyer un objet vide.
• Le module profile est déprécié, avec un retrait prévu en Python 3.17 ; cProfile reste disponible.
• Le ramasse-miettes générationnel de Python 3.13 est rétabli, à la place du ramasse-miettes incrémental livré dans les premières versions de 3.14.

Calendrier de support : où en sont vos versions ?

Chaque version reçoit deux ans de correctifs, puis trois ans de correctifs de sécurité uniquement, soit environ cinq ans au total. La prochaine version, 3.16, est prévue pour octobre 2027.

Faut-il migrer ?

• Vous êtes sur Python 3.10 ou plus ancien : c’est la priorité. Une faille découverte dans l’interpréteur ne sera plus corrigée. Visez 3.13 ou 3.14, qui ont déjà plusieurs mois de correctifs derrière eux, et vérifiez que vos dépendances les supportent.
• Vous êtes sur 3.11 à 3.14 : rien ne presse. Testez 3.15 dans votre intégration continue pour repérer tôt les problèmes d’encodage et les retraits d’API.
• Vous démarrez un projet : 3.15 est un choix raisonnable si vos bibliothèques principales publient déjà des paquets compatibles. Sinon, 3.14 reste un très bon point de départ.

Pour tester sans risque, ajoutez 3.15 à la matrice de votre CI, lancez la suite de tests avec -W error::DeprecationWarning pour faire remonter les usages condamnés, et cherchez dans votre code les appels à open() sans encoding. Si vos scripts manipulent des expressions régulières, c’est aussi l’occasion de les revérifier avec notre testeur de regex.

Sources

• Python Software Foundation, « What’s new in Python 3.15 », 9 octobre 2026 : https://docs.python.org/3.15/whatsnew/3.15.html
• Python Software Foundation, « PEP 790 – Python 3.15 Release Schedule » : https://peps.python.org/pep-0790/
• Python Developer’s Guide, « Status of Python versions » : https://devguide.python.org/versions/