Le JIT de CPython va être supprimé après le retrait de la PEP 836

Le compilateur à la volée (JIT, pour just-in-time) expérimental de CPython, l'interpréteur Python standard, devrait être supprimé de la branche main du projet. Ses auteurs ont retiré le 19 octobre 2026 la PEP 836, la proposition censée faire du JIT une fonctionnalité officielle. LWN.net a rapporté le 26 octobre que le code sera probablement retiré « assez rapidement », idéalement tôt dans le cycle de Python 3.16. Cela met fin, pour l'instant, à l'effort visant à rendre le Python standard plus rapide grâce à un compilateur intégré à l'interpréteur.

Un JIT transforme le code Python souvent exécuté en code machine pendant que le programme tourne. Les builds officiels de Python 3.15 pour Windows et macOS en incluent un à titre expérimental, désactivé par défaut.

Comment on en est arrivé là

Le déclencheur a été une annonce du Python Steering Council du 5 juin 2026, le groupe qui gouverne le langage. Il demandait une proposition formelle, appelée Standards Track PEP (Python Enhancement Proposal), plaidant pour faire du JIT une partie prise en charge de CPython.

Le conseil a fixé des conditions strictes :

Règle	Détail
Nouveau travail sur le JIT	Aucune nouvelle fonctionnalité, optimisation ou travail de performance sur main tant qu'une PEP n'est pas acceptée
Toujours autorisé	Corrections de bugs et correctifs de sécurité
Délai	Six mois pour soumettre une PEP et la trancher
Si aucune PEP n'est acceptée	« le code du JIT doit être supprimé de la branche main »
Python 3.15	Le conseil était « d'accord avec le statu quo pour 3.15 »

Le conseil a dit ne pas penser que l'équipe du JIT avait contourné le processus. Il a reconnu ne pas avoir été lui-même assez strict sur le processus.

Ce que proposait la PEP 836

Savannah Ostrowski, Ken Jin et Brandt Bucher ont rédigé la PEP 836, intitulée « JIT Go Brrr », qui visait Python 3.16. Elle ne demandait pas que le JIT soit déclaré pris en charge immédiatement. Elle proposait un parcours limité dans le temps, avec des objectifs mesurables.

• Avec le GIL : un build JIT au moins 5 % plus rapide que l'interpréteur normal la première année. Le GIL, ou verrou global de l'interpréteur (global interpreter lock), est le verrou qui ne laisse qu'un seul thread exécuter du code Python à la fois.
• Free-threaded : au moins 20 % plus rapide que l'interpréteur free-threaded d'ici la première bêta de Python 3.17.
• Changement de conception : passer de l'enregistrement de traces du code le plus exécuté à la compilation de méthodes entières.

Selon LWN, le conseil a répondu le 21 septembre. Il a estimé que la PEP répondait à ses questions, même si certaines réponses étaient moins convaincantes. Il voulait tout de même davantage d'éléments sur la sécurité, la prise en charge des plateformes et le comportement visible par les utilisateurs. Il a jugé « beaucoup, beaucoup trop tardive » une revue de compatibilité prévue pour la première release candidate de 3.17.

Selon InfoWorld, le conseil a aussi indiqué que la PEP manquait de détails sur le support à long terme, les tests de performance et les outils de débogage. Il a qualifié les objectifs de vitesse de trop optimistes.

Pourquoi les auteurs ont renoncé

« Nous n'avons pas le sentiment d'avoir la disponibilité personnelle nécessaire pour faire avancer la version actuelle », a écrit Ostrowski, citée par InfoWorld. « Le Steering Council place à juste titre la barre haut pour une proposition de cette ampleur », a-t-elle ajouté. L'équipe croit toujours en « la direction technique décrite dans la PEP », a-t-elle dit.

LWN note qu'Ostrowski est release manager de Python 3.16 et 3.17. Le message de retrait indiquait que le code de référence serait publié et lié depuis la PEP.

Les gains étaient réels mais modestes. La PEP 836 fait état d'une accélération de 4 à 12 % en moyenne géométrique dans Python 3.15 sur les principales plateformes. Selon InfoWorld, les gains profitaient surtout à certains types de programmes, comme les boucles serrées de longue durée.

Ce que cela signifie pour les développeurs

La plupart des utilisateurs de Python n'ont jamais activé le JIT, donc le code du quotidien n'est pas concerné. Quelques groupes devraient tout de même agir.

• Python 3.15 ne change pas. Le conseil a accepté le statu quo pour 3.15. Si vous définissez PYTHON_JIT=1 aujourd'hui, cela continue de fonctionner sur cette version.
• Ne misez pas sur un JIT dans 3.16. La suppression est attendue tôt dans le cycle de 3.16. Considérez toute accélération mesurée sur 3.15 comme temporaire.
• Des builds plus simples à venir. Les builds JIT ont besoin de LLVM, une boîte à outils de compilation, au moment du build. Les équipes qui compilent Python depuis les sources pourront probablement supprimer cette étape plus tard.
• Cherchez la vitesse ailleurs. Le conseil lui-même a cité des projets JIT distincts comme CinderX, Numba et PyTorch. Profilez d'abord votre code, puis choisissez l'outil adapté au chemin critique.
• Les forks peuvent continuer. Brett Cannon a dit qu'arrêter le travail dans main ne l'arrête pas ailleurs, rapporte LWN. Tout JIT relancé devrait franchir la même barre haute pour revenir.

Python 3.15.0 est sorti le 9 octobre avec un JIT plus rapide parmi ses nouveautés phares. Moins de trois semaines plus tard, ce même JIT n'a plus aucune voie pour devenir officiel.