El Consejo Directivo de Python cerró el camino al JIT de CPython. La PEP 836, que trazaba cómo convertirlo en una función soportada, se retiró el 19 de octubre y el código saldrá de la rama principal durante el ciclo de Python 3.16.
La razón está en los números: el JIT mejoraba entre 4% y 12% según la máquina, lejos del 20% que el proyecto se había puesto como meta.
Qué era y cuánto aceleraba
El JIT llegó a CPython en 2024 para la versión 3.13, de la mano de Brandt Bucher. Compila en tiempo de ejecución el código que más se repite para que corra como código máquina. En la práctica, los binarios oficiales de Windows y macOS lo incluyen apagado: se activa con PYTHON_JIT=1.
Los datos que la propia PEP 836 publicó miden el efecto en Python 3.15: 12,6% más rápido en una Mac con M3 Pro, 7,3% en AmpereOne, 6,9% en un i5-8400 y 4,7% en un Ryzen 5 3600X. Es una mejora real, pero concentrada en programas con bucles largos y ajustados.
Por qué el Consejo dijo no
En junio de 2026 el Consejo pausó el trabajo nuevo sobre el JIT y dio seis meses para una PEP de estándar que respondiera preguntas de mantenimiento, compatibilidad y métricas de éxito. La PEP 836 llegó en julio con un plan a dos años y medio.
El Consejo la encontró insuficiente en varios frentes: soporte a largo plazo, revisión de seguridad, paridad entre plataformas, compatibilidad con depuradores y perfiladores, y una revisión de compatibilidad con paquetes de PyPI que la PEP situaba en 2028. Para el Consejo, esa fecha llegaba «demasiado tarde».
Savannah Ostrowski, una de las autoras y release manager de 3.16, lo explicó sin rodeos: el listón era alto y el equipo no tenía el ancho de banda para llevar la versión actual adelante. La implementación de referencia quedará disponible y enlazada desde la PEP retirada, así que otros pueden retomarla.
Qué pierdes y qué no
Si usas Python de fábrica, hoy no pierdes velocidad: el JIT venía desactivado por defecto. Python 3.15, ya publicado, lo conserva. La desaparición afecta a la rama principal y a 3.16.
Tampoco desaparece la búsqueda de rendimiento. El intérprete adaptativo de Python 3.11, que especializa el bytecode según los tipos que ve, sigue siendo la vía principal y no exige cambiar código. Fuera de CPython quedan PyPy, CinderX de Meta, Numba y torch.compile para cargas específicas.
Lo que cambia para quien programa en Python
La apuesta del proyecto queda en free-threading y mejoras incrementales del intérprete, no en un JIT propio. Para un equipo que planeaba esperar a que CPython cerrara la brecha con lenguajes compilados, el cálculo se rompe: la velocidad hay que buscarla en el ecosistema o en otra herramienta.
También deja una lección de gobernanza. Un proyecto de esta escala no se sostiene con buena voluntad: la PEP reconoce aportes de Arm, FastAPI Labs y OpenAI, y aun así el equipo no pudo comprometer el mantenimiento que el Consejo pedía.
Si tu plan de rendimiento era esperar el JIT de CPython, ese plan acaba de perder su fecha. La pregunta útil ahora es cuánto de tu cuello de botella es lenguaje y cuánto es diseño, porque el intérprete no va a resolverlo solo.
Más en: Programación, Tecnología
