Python : cinq quais le 1er octobre, et le tien n'a pas forcément de train Windows

Le tableau d'affichage n'a qu'un titre, et cinq quais en dessous. Tu arrives avec ta valise, celle qui a le numéro de ta version collé sur la poignée, et tu cherches le train qui s'appelle « la mise à jour ». Il y en a cinq. Trois n'ont pas de wagon Windows. L'un est le dernier de sa ligne. Et sur le côté du hall, une affiche parle d'une porte qui coince : ce n'est même pas un quai.

Le 1er octobre 2026, Pablo Galindo publie sur Python Insider une seule annonce pour Python 3.10.22, 3.11.17, 3.12.15, 3.13.16 et 3.14.8. La signature du bas nomme l'équipe de release : Hugo van Kemenade, Thomas Wouters, Pablo Galindo Salgado. Le titre dit qu'elles sont là. Le corps dit qu'elles ne font pas le même trajet.

Cinq horaires, trois sans wagon

3.10.22 est la dernière de la série. Après cinq ans, écrit le billet, 3.10 a atteint sa fin de vie et ne recevra plus de correctifs de sécurité. Si tu es encore dessus, la phrase qui suit est une consigne, pas une politesse : prévois le passage à une version encore supportée.

3.11 reste en correctifs de sécurité seulement, jusqu'en octobre 2027, comme le décrit le PEP 664. Ces correctifs sortent quand il le faut, sans calendrier fixe. Tu n'as pas un mardi par mois. Tu as « au besoin », et encore un an de cette formule.

3.10.22 et 3.11.17 sont livrées en sources seules. Pas d'installeur Windows, pas d'installeur macOS. Les derniers de leur série à en avoir eu étaient 3.10.11 et 3.11.9. Ces deux tarballs-ci contiennent des correctifs de sécurité, pas des nouveautés. Si ton réflexe est le fichier .exe ou le paquet macOS, le quai est vide. Le code est là. Le wagon que tu cherches a été décroché plus tôt.

3.12.15 est aussi une livraison de sécurité en sources seules. Le support sécurité de la série continue jusqu'en octobre 2028. 3.13.16 est la dernière release de maintenance complète de 3.13 : les suivantes ne contiendront plus que des correctifs de sécurité. 3.14.8 est une release de maintenance. Et le billet est net sur le quai d'à côté : 3.13.16 et 3.14.8 ont, elles, des installeurs binaires. Deux trains avec wagon. Trois sans. Le titre unique ne le dit pas. Le paragraphe, si.

Le même carton de sécurité, pas le même contenu

La liste des correctifs n'est pas photocopiée cinq fois. Une première section vaut pour les cinq. Une deuxième ne nomme que 3.10.22, 3.11.17, 3.12.15 et 3.13.16. Une troisième ne parle que de 3.13.16 et 3.14.8. Une dernière ne concerne que 3.10.22. Je ne recopie pas les changelogs liés. Je lis le découpage du billet.

Dans la liste commune, six CVE. L'une d'elles change de geste selon le quai. CVE-2026-19553 : ssl.SSLContext.wrap_bio() valide désormais server_side, server_hostname et session, et asyncio valide aussi les server_hostname TLS. Sur 3.10, 3.11 et 3.12, un nom d'hôte manquant alors que check_hostname est activé émet un DeprecationWarning, pour la compatibilité. Sur 3.13 et après, le même cas lève un ValueError. Le correctif est dans les cinq. L'exception, non.

Deux CVE ne sont listées que jusqu'à 3.13.16. Pour CVE-2026-82049, le billet explique pourquoi 3.14 n'est pas dans la phrase : 3.14 et les suivantes étaient déjà protégées, parce que os.link() suit les liens symboliques depuis Python 3.14.0b1. L'autre, CVE-2026-87910, est dans la même section, celle qui s'arrête à 3.13. Le billet ne lui donne pas la même phrase. Je ne la lui prête pas.

L'OpenSSL embarqué passe à 3.5.9, et seulement là où il y a des binaires. Dans 3.13.16, ça vise Windows, macOS et Android, en quittant OpenSSL 3.0.21 pour la série 3.5 LTS. Dans 3.14.8, Windows, macOS, Android et iOS. Les livraisons en sources seules, 3.10 à 3.12, n'embarquent pas OpenSSL. Ton système, s'il en a un, n'est pas ce tarball.

Et le quai 3.10 a un bagage en plus. gh-149018 : une meilleure protection contre le flood de hash XML dans xml.parsers.expat et xml.etree.ElementTree, quand c'est compilé avec libexpat 2.8.0 ou plus récent. Cette protection était déjà dans 3.11.16. Le dernier train de 3.10 rattrape un colis que le quai d'à côté avait déjà chargé.

L'affiche sur la porte du hall

En bas, une section à part. Elle ne sort aucune version. Elle parle de macOS 27.0. IDLE, ou une autre application graphique qui passe par tkinter, peut se bloquer quand une commande de menu ouvre une boîte de dialogue. L'exemple donné : About IDLE, Settings, Open Module. Plage tournante, et Force Quit pour s'en sortir.

La cause, selon le billet, est un changement de comportement du système dans macOS 27.0, dont on pense qu'il touche toutes les versions actuelles de la boîte à outils Tk, et donc tkinter dans toutes les versions actuelles de Python. Le conseil est au conditionnel : si tu dépends d'applications Tk, tu peux envisager de retarder l'installation de macOS 27.0, en attendant un contournement côté Tk ou côté macOS, ou de vérifier que ton usage n'est pas touché. Le suivi est l'issue #158053.

Je ne date pas macOS 27. Le billet ne le date pas. Je ne dis pas que chaque Mac plante. Il dit « may », et « believed to ». L'affiche est dans le hall des cinq quais parce que le même jour, la même équipe, avait ça à dire. Ce n'est pas un sixième numéro de Python.

✍️ À toi : la version que tu lances vraiment, python3 --version, et si tu la mets à jour par un installeur, un tarball, ou le paquet de ta distro. Le billet décrit cinq quais. Ta machine n'en a qu'un.

Cinq numéros, un titre. Trois quais sans installeur Windows ni macOS. Un dernier départ, le 3.10, qui ne reviendra pas. Un 3.13 qui, à partir de maintenant, ne fera plus que de la sécurité. Et sur le mur, une porte macOS qui peut coincer IDLE, quel que soit le train que tu as pris. Le tableau a l'air d'une seule mise à jour. Les horaires, eux, ne sont pas les mêmes.