El JIT de CPython se eliminará tras la retirada de la PEP 836

Se espera que el compilador just-in-time (JIT) experimental de CPython, el intérprete estándar de Python, se elimine de la rama main del proyecto. Sus autores retiraron el 19 de octubre de 2026 la PEP 836, la propuesta destinada a convertir el JIT en una función oficial. LWN.net informó el 26 de octubre de que el código probablemente saldrá «bastante pronto», idealmente al inicio del ciclo de Python 3.16. Eso pone fin, por ahora, al esfuerzo por hacer más rápido el Python estándar con un compilador integrado en el intérprete.

Un JIT convierte el código Python que se ejecuta con frecuencia en código máquina mientras el programa se ejecuta. Las compilaciones oficiales de Python 3.15 para Windows y macOS incluyen uno como experimento, desactivado por defecto.

Cómo se llegó hasta aquí

El detonante fue un anuncio del Python Steering Council del 5 de junio de 2026, el grupo que gobierna el lenguaje. Pedía una propuesta formal, llamada Standards Track PEP (Python Enhancement Proposal), que defendiera el JIT como una parte con soporte de CPython.

El consejo fijó condiciones firmes:

Regla	Detalle
Nuevo trabajo en el JIT	Ninguna función nueva, optimización ni trabajo de rendimiento en main hasta que se acepte una PEP
Sigue permitido	Correcciones de errores y de seguridad
Plazo	Seis meses para presentar y resolver una PEP
Si no se acepta ninguna PEP	«el código del JIT debe eliminarse de la rama main»
Python 3.15	El consejo estaba «conforme con el statu quo para 3.15»

El consejo dijo que no creía que el equipo del JIT se hubiera saltado el proceso. Admitió que él mismo no había sido lo bastante estricto con el proceso.

Qué proponía la PEP 836

Savannah Ostrowski, Ken Jin y Brandt Bucher escribieron la PEP 836, titulada «JIT Go Brrr», dirigida a Python 3.16. No pedía declarar el JIT con soporte de inmediato. Proponía un camino con plazo limitado y objetivos medibles.

• Con el GIL: la compilación con JIT, al menos un 5 % más rápida que el intérprete normal en el primer año. El GIL, o bloqueo global del intérprete (global interpreter lock), es el bloqueo que solo deja que un hilo ejecute código Python a la vez.
• Free-threaded: al menos un 20 % más rápida que el intérprete free-threaded para la primera beta de Python 3.17.
• Cambio de diseño: pasar de registrar trazas del código más ejecutado a compilar métodos completos.

Según LWN, el consejo respondió el 21 de septiembre. Dijo que la PEP respondía a sus preguntas, aunque algunas respuestas eran menos convincentes. Aun así, quería más sobre seguridad, compatibilidad con plataformas y comportamiento visible para los usuarios. Calificó de «demasiado, demasiado tarde» una revisión de compatibilidad prevista para la primera release candidate de 3.17.

Según InfoWorld, el consejo también dijo que a la PEP le faltaban detalles sobre soporte a largo plazo, pruebas de rendimiento y herramientas de depuración. Calificó los objetivos de velocidad de demasiado optimistas.

Por qué la retiraron sus autores

«No sentimos que tengamos la disponibilidad personal para sacar adelante la versión actual», escribió Ostrowski, según cita InfoWorld. «El Steering Council, con razón, pone el listón alto para una propuesta de este alcance», añadió. El equipo sigue creyendo en «la dirección técnica descrita en la PEP», dijo.

LWN señala que Ostrowski es la release manager de Python 3.16 y 3.17. La publicación de la retirada decía que el código de referencia se publicaría y se enlazaría desde la PEP.

Las mejoras fueron reales pero modestas. La PEP 836 informa de una aceleración del 4 al 12 % en media geométrica en Python 3.15 en las principales plataformas. Según InfoWorld, las mejoras ayudaban sobre todo a ciertos tipos de programas, como los bucles intensivos de larga duración.

Qué significa para los desarrolladores

La mayoría de los usuarios de Python nunca activó el JIT, así que el código del día a día no se ve afectado. Aun así, algunos grupos deberían actuar.

• Python 3.15 no cambia. El consejo aceptó el statu quo para 3.15. Si hoy defines PYTHON_JIT=1, sigue funcionando en esa versión.
• No planifiques contando con un JIT en 3.16. Se espera la eliminación al inicio del ciclo de 3.16. Trata cualquier aceleración que hayas medido en 3.15 como temporal.
• Compilaciones más sencillas a la vista. Las compilaciones con JIT necesitan LLVM, un conjunto de herramientas de compilación, en el momento de compilar. Los equipos que compilan Python desde el código fuente probablemente podrán eliminar ese paso más adelante.
• Busca velocidad en otra parte. El propio consejo mencionó proyectos JIT independientes como CinderX, Numba y PyTorch. Perfila primero tu código y luego elige la herramienta que encaje con la ruta crítica.
• Los forks pueden continuar. Brett Cannon dijo que detener el trabajo en main no lo detiene en otros lugares, según LWN. Cualquier JIT revivido tendría que superar el mismo listón alto para volver.

Python 3.15.0 salió el 9 de octubre con un JIT más rápido como uno de sus cambios destacados. Menos de tres semanas después, ese mismo JIT no tiene camino para convertirse en oficial.