Le JIT a été intégré, mais n’a pas été approuvé
Le compilateur JIT expérimental de Python est arrivé dans CPython 3.13 en tant que fonctionnalité activable sur option, à partir de travaux commencés fin 2023 et début 2024. Le développeur principal Brandt Bucher a initialement fusionné le JIT copy-and-patch, dans le but d’améliorer les performances à l’exécution.
Cependant, le JIT n’a jamais obtenu d’approbation formelle à long terme. Il a été livré dans le cadre de la PEP 744, une PEP informative qui se contentait de décrire la fonctionnalité, plutôt qu’une PEP Standards Track qui aurait consolidé sa place et l’engagement de maintenance continue. Cette lacune procédurale a rendu son avenir incertain dès le départ.
Il ne s’agit pas d’un retour en arrière dû à des bugs ; le code lui-même fonctionnait. Le projet Python permet plutôt de livrer des fonctionnalités expérimentales sans engagement permanent, ce qui crée un espace d’innovation sans imposer automatiquement à l’équipe principale un support à durée indéterminée. La suppression du JIT découle de cette absence de consensus formel, et non d’un défaut technique.
Le Steering Council de Python a fini par poser un ultimatum : obtenir une PEP Standards Track, ou le JIT serait supprimé. Cette décision a souligné que si livrer du code expérimental est une chose, convaincre la communauté et les mainteneurs de s’engager sur des ressources à durée indéterminée est un défi bien plus grand dans le développement open source.
Le conseil demandait des preuves, pas des promesses
Le steering council de Python, peu convaincu par l’introduction informelle du JIT, a émis un ultimatum en juin 2026 : soumettre et faire adopter une proposition Standards Track dans un délai de six mois, faute de quoi le code du JIT expérimental serait retiré de la branche main. Il ne s’agissait pas d’une suggestion, mais d’une échéance ferme pour une fonctionnalité qui avait contourné la gouvernance habituelle.
En réponse, Savannah Savannah Ostrowski, Ken Jin et Brandt Bucher ont soumis la PEP 836, intitulée à juste titre « JIT Go Brrr: The Path to a Supported JIT Compiler for CPython », en juillet 2026. La critique en 10 points du conseil a été rapide et sans concession. Il a reproché à la PEP de ne pas accorder suffisamment d’attention à la sécurité, qualifiée de « domaine insuffisamment traité », et a jugé ses projections de performance et d’impact sur les utilisateurs « trop optimistes ».
Le rejet le plus accablant concernait peut-être l’examen de compatibilité proposé, prévu pour la release candidate de Python 3.17 en août 2028. Le conseil a jugé ce calendrier « beaucoup, beaucoup trop tardif », soulignant son exigence de garanties immédiates et solides. Sans feuille de route convaincante, l’avenir du JIT paraissait de plus en plus sombre, malgré sa promesse initiale.
Une proposition prometteuse a manqué de personnes
L’ultimatum du Steering Council de Python pesait lourd, mais une proposition prometteuse n’a pas réussi à s’imposer. Le 19 octobre 2026, Savannah Savannah Ostrowski, release manager de Python 3.16 et 3.17, a officiellement retiré la PEP 836, la proposition « JIT Go Brrr » destinée à faire accéder le JIT au statut Standards Track. Elle en a donné la raison suivante : un manque flagrant de « disponibilité personnelle pour porter la version actuelle plus loin ».
Il ne s’agissait pas d’une déclaration selon laquelle les JIT seraient sans valeur ; bien au contraire. Savannah Ostrowski et son équipe restaient convaincues du potentiel de cette technologie pour améliorer les performances de Python. Le retrait reflétait l’ampleur de l’effort technique et politique nécessaire pour satisfaire les exigences rigoureuses du conseil, qui comprenaient de répondre aux préoccupations de sécurité et de démontrer des gains de performance plus solides que les accélérations modestes de 4 à 12 % en moyenne géométrique observées dans des benchmarks restreints.
Les retours du conseil avaient été directs : il qualifiait la sécurité de « domaine insuffisamment traité » et jugeait l’examen de compatibilité proposé en août 2028 pour Python 3.17 « beaucoup, beaucoup trop tardif ». Faute de ressources dédiées pour traiter ces points de manière exhaustive, la PEP 836 ne pouvait pas avancer. Pour le contexte de l’introduction initiale, moins formelle, du JIT, consultez PEP 744 – JIT Compilation.
La conséquence est désormais quasi certaine : le code du JIT expérimental sera supprimé de la branche principale de CPython au début du cycle de développement de Python 3.16. La brève incursion de Python dans un JIT intégré à l’arborescence semble toucher à sa fin, victime des réalités de l’open source, où la livraison du code est souvent la partie la plus facile.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Le véritable goulot d’étranglement est la responsabilité à long terme
Fusionner du code marque le début du développement open source, et non sa fin. La suppression imminente du JIT de la branche principale de CPython illustre une leçon essentielle : la responsabilité va au-delà des commits initiaux. Les mainteneurs assument une charge continue : examens de sécurité, risques de compatibilité, coûts mémoire et support à long terme. L’équipe du JIT, malgré sa confiance dans la technologie, n’a pas pu soutenir ce fardeau.
Ce résultat ne doit pas être interprété comme un arrêt des efforts de performance de Python. Le JIT était une fonctionnalité expérimentale, activable sur option. Une grande partie des gains de vitesse récents de CPython, y compris les améliorations substantielles de Python 3.11 et 3.12, provient de l’interpréteur adaptatif spécialisant, une stratégie d’optimisation distincte et toujours en cours.
En outre, cette décision ne signe pas la fin du développement de JIT pour Python en général. D’autres projets comme PyPy, Numba et PyTorch Inductor continuent de s’appuyer sur la compilation JIT. Ces solutions, qui répondent à des charges de travail et à des environnements d’exécution différents, évoluent en dehors du développement du cœur de CPython, ce qui montre que le concept de JIT reste essentiel pour certaines applications Python hautes performances.
Questions fréquentes
Pourquoi CPython supprime-t-il son JIT expérimental ?
Le JIT ne disposait pas d’une PEP Standards Track approuvée, faisait face à des préoccupations non résolues en matière de sécurité et de compatibilité, et ses mainteneurs ne pouvaient pas consacrer la disponibilité nécessaire pour mener la proposition à son terme.
Le JIT a-t-il été supprimé à cause de bugs ?
Non. La décision portait sur la gouvernance, la maintenance à long terme, l’examen de sécurité et la question de savoir si les bénéfices attendus justifiaient les coûts.
Quelle était la différence entre la PEP 744 et la PEP 836 ?
La PEP 744 documentait le JIT expérimental, mais avait un caractère informatif. La PEP 836 visait à obtenir l’approbation formelle d’un JIT pris en charge, mais son auteure principale l’a retirée.
Cela signifie-t-il que Python n’aura jamais de JIT ?
Non. La décision concerne le JIT de la branche principale de CPython ; des projets indépendants et de futures propositions peuvent toujours poursuivre la compilation JIT.