Un 4–12 % más rápido en la media geométrica de pyperformance: eso es lo que daba el JIT experimental de CPython en Python 3.15. El plan para convertirlo en una pieza estable pedía llegar al 20 % en dos años, y sus autores lo han retirado. Según LWN, el 27 de octubre de 2026, el JIT va a salir de la rama main de CPython.
Qué se va y qué se queda
El compilador JIT entró en main con Python 3.13, con un diseño copy-and-patch descrito en PEP 744, y siempre ha sido experimental y opcional. Los binarios oficiales de Windows y macOS lo traen compilado pero desactivado (se activa con PYTHON_JIT=1), y distribuciones como Fedora y Gentoo hacen lo mismo. Para compilarlo hace falta LLVM, que en 3.15 pasó a ser LLVM 21.
PEP 836, firmado por Savannah Ostrowski, Ken Jin y Brandt Bucher el 2 de julio de 2026, proponía un camino de dos años y medio para que dejara de ser experimental. Su estado es ahora Withdrawn, con fecha de 19 de octubre de 2026. LWN e InfoWorld sitúan la retirada del código al principio del ciclo de desarrollo de Python 3.16.
Lo que no se va, según el propio PEP, es la infraestructura que el JIT dejó en el intérprete: el DSL de bytecode y las micro-operaciones (uops), que reducen el mantenimiento del intérprete aunque no haya JIT encima.
Cuánto daba y cuánto se pedía
| Resultado o meta | Fuente | |
|---|---|---|
| JIT en 3.15, Tier 1 (junio de 2026) | 4,7 % (Windows) a 12,6 % (macOS M3 Pro) | PEP 836 |
| JIT en 3.15, x86-64 Linux | 7–8 % | What's New 3.15 |
| JIT en 3.15, AArch64 macOS | 11–12 % | What's New 3.15 |
| Meta del año 1 (beta de 3.16) | ≥ 5 % con GIL | PEP 836 |
| Meta del año 2 (beta de 3.17) | ≥ 20 % con free-threading | PEP 836 |
La media esconde mucha dispersión: el What's New de 3.15 reconoce que, según el benchmark, el JIT iba desde un 15 % más lento hasta más del doble de rápido. Y la meta del 20 % no era sobre el intérprete clásico, sino sobre el build sin GIL, que el PEP trataba como el objetivo principal. El JIT ni siquiera era compatible con free-threading todavía: hacerlo seguro era uno de los trabajos del primer año, con una pérdida inicial estimada del 1–2 %.
Qué significa
Para quien ejecuta Python en producción, el impacto inmediato es pequeño: casi nadie lo tenía activado, porque había que pedirlo expresamente. Si en algún servicio lo activaste con PYTHON_JIT=1 en 3.15, esa versión ya publicada no cambia; lo que desaparece es la expectativa de que en 3.16 o 3.17 fuera a ser más rápido o estable.
Para el ecosistema es un mensaje sobre prioridades. Sin JIT en el núcleo, lo previsible es que el rendimiento de CPython en los próximos años venga sobre todo de free-threading y del intérprete especializado, no de un JIT en el núcleo. El propio PEP recuerda que hay JIT fuera de CPython que usan la interfaz de PEP 523, como CinderX y TorchDynamo, y que PyPy y GraalPy consiguen más velocidad en algunos programas, a cambio de compatibilidad con extensiones, versiones soportadas y herramientas.
Me parece la decisión honesta. Un JIT en el núcleo obliga a debuggers, profilers y distribuidores a cargar con él; con un 4–12 % de media y LLVM como requisito de compilación, el coste para todos era alto. Mantener el trabajo fuera de main deja la puerta abierta a que vuelva con cifras que lo justifiquen.
La cuestión pendiente es si alguien retoma el proyecto fuera del árbol principal: tendría que superar el mismo listón para volver a entrar.
Fuentes
- Python's experimental JIT to be removed, LWN.net, 27 de octubre de 2026.
- PEP 836 – JIT Go Brrr: The Path to a Supported JIT Compiler for CPython, Python Enhancement Proposals.
- What's New In Python 3.15, documentación de Python.
- Python jettisons the native JIT, at least for now, InfoWorld.