Le Python Language Summit 2026 débat de Rust et d'un nouveau GC

La Python Software Foundation a publié le 30 septembre ses comptes rendus du Python Language Summit 2026. Le summit est l'endroit où les développeurs du cœur de Python débattent de l'avenir du langage, avant que quoi que ce soit devienne une proposition formelle. L'un des plans les plus concrets venait de l'équipe Rust for CPython : faire entrer Rust pas à pas dans CPython, l'interpréteur Python principal.

Le résumé de la PSF indique que 47 développeurs du cœur et invités se sont réunis le 14 juillet 2026 à Cracovie, en Pologne, lors d'EuroPython 2026. Ils ont écouté 10 présentations complètes et 5 présentations éclair. C'était le premier summit en Europe depuis Florence en 2011. « Désormais, le Python Language Summit alternera chaque année entre PyCon US et EuroPython », écrit la PSF. Seth Larson a rédigé les comptes rendus, et LWN les a signalés à ses lecteurs le jour même.

Rust passe de l'expérience au plan

David Hewitt a parlé au nom de l'équipe Rust for CPython, dirigée par Kirill Podoprigora et Emma Smith, qui compte environ 60 développeurs. L'équipe veut ajouter Rust à CPython petit à petit, en commençant par de petits modules autonomes.

Le premier candidat est zlib, le module de compression, construit sur la bibliothèque zlib-rs. Le compte rendu de Python Insider cite l'équipe, pour qui zlib-rs est « plus rapide que zlib et zlib-ng sur de nombreuses plateformes ». L'argument en faveur de Rust est la sûreté. Les tickets portant l'étiquette type-crash de CPython sont passés de 82 en 2021 à 353 prévus en 2026.

Les phases du plan s'étalent sur Python 3.16 en octobre 2027, 3.17 en octobre 2028 et 3.18 en 2029 ou plus tard. La prise en charge de Rust sur les différentes plateformes est désormais « de moins en moins un souci », selon l'équipe. Hewitt a aussi été direct sur l'état final : « il serait malhonnête de dire que Rust resterait optionnel pour toujours ». CPython restera « un projet bilingue pendant un temps considérable ».

Un nouveau plan pour le ramasse-miettes

Mark Shannon a indiqué que le ramasse-miettes, le travail qui repère et libère la mémoire inutilisée, occupe environ 11,67 % du temps d'exécution de Python. Il a proposé un hybride de deux conceptions. Un ramasse-miettes générationnel examine le plus souvent les objets récents, car « la plupart des objets meurent jeunes ». Un ramasse-miettes incrémental fait son travail par petites tranches au lieu d'un long arrêt.

La raison, ce sont les temps de pause. Shannon a chiffré les pauses incrémentales à « quelques dizaines de millisecondes », contre environ 3 secondes pour l'approche générationnelle. Dans sa conception, la jeune génération démarre à 20 Mo. La salle était divisée sur un point : Python doit-il proposer des réglages à la Java pour ajuster le ramasse-miettes ?

Après le free-threading : un modèle de concurrence plus sûr

Le free-threading est la nouvelle version de Python capable d'exécuter des threads vraiment en parallèle. Tobias Wrigstad, Fridtjof Stoldt et Donghee Na se sont demandé ce qui vient ensuite. Ils ont proposé Behavior-Oriented Concurrency, un modèle où les tâches déclarent les données dont elles ont besoin avant de s'exécuter.

Chaque donnée partagée se trouve dans un « cown », pour concurrent owner, qu'une seule tâche peut utiliser à la fois. Un décorateur @when nomme les cowns dont une tâche a besoin. Selon les intervenants, cette conception empêche les interblocages et les accès concurrents. Une preuve de concept, bocpy, tourne déjà sur Python stable grâce aux sous-interpréteurs. Le summit n'a soutenu aucune approche en particulier et a plaidé pour davantage de recherche.

Le typage, un espace std et un démarrage plus rapide

Présentation	Intervenant	L'idée
PEP 827, manipulation de types	Michael J. Sullivan	Des types qui calculent d'autres types, par exemple dériver d'un seul modèle les types ORM de création et de mise à jour
Espaces de noms	Pablo Galindo Salgado	Un espace de noms std de premier niveau, pour que import std.json désigne toujours la bibliothèque standard
Instantanés mémoire	Hood Chatham	Sauvegarder un interpréteur démarré et le restaurer, ce qui fait passer le « Hello, world » de Pyodide de 1,406 s à 0,353 s
Prise en charge de macOS	Ned Deily	Ajouter macOS à la PEP 11, la politique de prise en charge des plateformes, et moderniser un installateur qui cumule 25 ans de dette technique

Sullivan a souligné que « les utilisateurs ne sont pas censés écrire de tels types, ou alors très rarement ». Galindo Salgado a promis que l'ancien import json continuerait de fonctionner : « On ne peut pas casser le monde, ce serait mal. » Le principal risque des instantanés est la sécurité. Une graine de hachage censée être aléatoire à chaque exécution serait figée et partagée.

Ce que cela signifie pour les développeurs

Rien n'est encore décidé. Le summit est une discussion, et chaque changement doit encore passer par une PEP, la procédure de proposition formelle de Python. Lisez ces comptes rendus comme une carte de la direction que prennent les prochaines versions.

Si vous compilez CPython depuis les sources, commencez à vérifier la question de Rust. Cela concerne les distributions Linux, les cartes embarquées et les plateformes inhabituelles. Les propres mots de Hewitt disent que Rust ne restera pas optionnel pour toujours. Assurez-vous qu'une chaîne d'outils Rust existe pour chaque plateforme que vous livrez, avant que le module zlib ne rende la question pressante.

Arrêtez de nommer vos fichiers locaux comme des modules de la bibliothèque standard. Un fichier json.py ou random.py dans votre projet peut déjà masquer le vrai module aujourd'hui. L'espace de noms std doit régler ce problème, mais de bons noms le règlent dès maintenant.

Si votre service souffre de longues pauses du ramasse-miettes, suivez le travail de Shannon. N'y bâtissez pas encore de réglages, puisque le summit était divisé sur l'idée même d'en proposer.

Les auteurs de bibliothèques devraient lire la PEP 827. Les mainteneurs d'ORM et de frameworks en sont le public. Les développeurs d'applications en profiteront surtout sans écrire eux-mêmes ces types.

Essayez bocpy si vous écrivez du Python concurrent. Il tourne sur le Python actuel, et les retours d'aujourd'hui influencent ce que l'équipe du cœur choisira de construire.