El motor JIT (Just-in-Time) experimental de CPython no seguirá en la rama principal. La propuesta que iba a convertirlo en una pieza soportada del intérprete, PEP 836, se retiró el pasado 19 de octubre y con ella se cierra un intento que llevaba tres años buscando hueco entre las prioridades del lenguaje. Los autores, Brandt Bucher y Savannah Ostrowski, no han desaparecido del mapa: han reconocido que no tenían recursos para sostener la versión actual del documento. Ese detalle dice más del estado del proyecto que cualquier comunicado.
Para quien programa en Python todos los días, la noticia tiene dos lecturas. La primera es que el lenguaje no va a acelerarse por la vía del compilador en el corto plazo. La segunda es que el mecanismo que debía decidirlo funcionó: el steering council pidió un plan de mantenimiento, evaluó la evidencia de rendimiento y dijo que no cuando el plan no llegó. En un ecosistema donde casi todo se aprueba por entusiasmo, ver un rechazo técnico documentado es casi una rareza, pero Python es así.
El asunto importa porque Python carga con una vieja contradicción: sirve de puerta de entrada a medio sector y, a la vez, es el lenguaje que más se queja de su propia velocidad. Cada año aparece una solución que promete cerrar esa brecha y cada año la solución choca con la misma pared, que no es técnica, sino de ingeniería de mantenimiento.
Después de todo, tocar un lenguaje como Python no es fácil, buena parte de las soluciones empresariales dependen de este lenguaje, y en IA y Machine Learning, es el rey por excelencia, así que poner una mano encima de su especificación requiere mucho más que buenas ideas, requiere de compromisos y planes claros.
¿Qué era el JIT y qué prometía en Python?
Un compilador just-in-time o JIT, traduce el código a instrucciones de máquina mientras el programa se ejecuta, en lugar de interpretarlo línea a línea. La promesa es sencilla de contar y difícil de cumplir: menos trabajo repetido, más velocidad, sin que el programador cambie una sola coma de su código.
El proyecto de CPython arrancó con ese objetivo y con un alcance limitado, pensado para bucles de larga duración y cargas con mucho cálculo. Las mejoras existían, pero eran modestas y desiguales, según el propio análisis que el consejo usó para decidir.
Un JIT que acelera un 15% algunos programas y deja igual al resto no es un cambio de época, es una optimización que hay que justificar cada trimestre frente a otros parches que sí benefician a todo el mundo.
El otro frente era el mantenimiento. Un JIT dentro de un intérprete toca el compilador, el intérprete de bytecode, el depurador y el perfilador al mismo tiempo, y cada uno de esos sistemas tiene su propio ritmo de cambio. Ahí es donde el proyecto se quedó sin aire.
El «No» del consejo
La secuencia está documentada y resulta instructiva. El trabajo se pausó en junio de 2026 hasta que existiera un documento que explicase cómo integrar y sostener el JIT en la base de Python. El equipo respondió con dos propuestas: PEP 744 explicaba qué hacía el compilador y PEP 836 intentaba responder lo que faltaba, desde el mantenimiento hasta la evaluación del rendimiento.
El consejo encontró huecos concretos: cómo se sostendría el código a largo plazo, cómo se mediría la ganancia con criterios comparables y cómo conviviría con las herramientas de depuración y perfilado. A eso sumó una objeción menos amable y más útil, que el documento era demasiado optimista sobre las cifras que cabía esperar. La crónica de InfoWorld recoge el cierre del asunto y la frase de Ostrowski sobre el ancho de banda del equipo.
Nadie ha prohibido que otros continúen el trabajo por su cuenta ni que lo empaqueten en una compilación alternativa de CPython. Lo que ha cambiado es el precio de volver: quien quiera devolver ese código a la rama principal tendrá que superar el mismo listón de soporte, medición e integración, y ese listón ahora está escrito y es público.
El intérprete adaptativo sigue haciendo el trabajo sucio
La retirada del JIT no deja a Python donde estaba en 2022. El intérprete adaptativo que llegó con la versión 3.11 cambia el bytecode por versiones especializadas según los tipos que ve en ejecución, y lo hace sin que el programador reescriba nada. No alcanza la velocidad de JIT, pero reparte la mejora entre todo el código y no solo entre los bucles cerrados. Al final, la mejora global iguala o supera al JIT que se buscaba implementar, así que su retirada no es dolorosa.
Esa es la razón por la que la decisión tiene sentido. El equipo de CPython lleva años empujando mejoras graduales que suman poco a poco, y el JIT competía por el mismo tiempo de revisión con menos retorno medible. Cuando el recurso escaso es la atención de cinco personas, la comparación se resuelve sola.
| Vía |
Qué aporta |
Estado |
| Intérprete adaptativo (3.11+) |
Bytecode especializado por tipos, sin tocar el código |
En producción |
| JIT experimental de CPython |
Acelera bucles largos, ganancia desigual |
Retirado de la rama principal |
| PyPy |
JIT maduro, hasta diez veces más rápido en cargas favorables |
Proyecto aparte, retrasado respecto a CPython |
| CinderX (Meta) |
JIT como complemento instalable |
Experimental |
Lo que le queda a quien necesita velocidad
Si tu código pasa el día dentro de un bucle numérico, la salida sigue siendo la misma que hace cinco años: mover ese núcleo a una biblioteca compilada, a C, a Rust o a un motor como NumPy. La otra opción es cambiar de intérprete y aceptar el precio de PyPy, que arrastra retraso respecto a la versión de referencia y problemas con los módulos de extensión en C.
Para quien escribe herramientas y prefiere un lenguaje con garantías de rendimiento desde el principio, el debate tiene otro nombre. Lo contamos al analizar SolidCraft y el CAD paramétrico escrito en Rust, donde la elección del lenguaje no es una preferencia estética, sino una decisión sobre qué se puede prometer al usuario. Python gana en velocidad de escritura y pierde en velocidad de ejecución, y el JIT era el intento de recortar esa desventaja sin renunciar a lo primero.
Hay una tercera puerta que casi nadie usa y que el propio consejo señaló: mantener el JIT fuera de CPython, como proyecto satélite. Un build alternativo con el compilador dentro permitiría a los interesados medirlo sin cargar al proyecto principal con su mantenimiento. Es la salida elegante, y también la que menos incentivos tiene, porque nadie financia un fork que solo usan cuatro equipos.
El mensaje incómodo para el resto del ecosistema
Lo que ha pasado con el JIT de CPython es un caso de estudio sobre gobernanza técnica. Un grupo de voluntarios propuso una mejora grande, la documentó, la defendió y recibió un no razonado con tres motivos concretos. No hubo filtraciones ni guerra de egos en público, y el código sigue disponible para quien quiera retomarlo.
Comparado con lo que ocurre en otros proyectos, la escena es casi ejemplar. En el software libre abundan las decisiones de rendimiento tomadas por demo y anunciadas en una conferencia, con la medición real llegando dos años después y nadie asumiendo el coste de mantenerla. Aquí el coste se puso por delante y esa fue la razón del rechazo.
No es el final del Python rápido
El lenguaje no se ha vuelto más lento porque haya un PEP retirado. La versión estable sigue siendo la misma y el intérprete adaptativo continúa mejorando en cada entrega, aunque sin titulares. Lo que se ha cerrado es una vía concreta, no el problema.
Dentro de dos años, la pregunta relevante no será si CPython tiene JIT, sino si el modelo de gobernanza aguanta la presión de un ecosistema que le pide a la vez estabilidad y velocidad.
Si el siguiente intento llega con mediciones comparables y un plan de mantenimiento firmado, el consejo tendrá difícil decir que no. Y si no llega, el hueco lo ocuparán los intérpretes alternativos, que ya saben cómo se hace y llevan una década esperando su turno.
