El JIT se incorporó, pero no obtuvo aprobación
El compilador JIT experimental de Python llegó en CPython 3.13 como una funcionalidad opcional, a partir del trabajo iniciado a finales de 2023 y principios de 2024. El desarrollador principal Brandt Bucher incorporó inicialmente el JIT de copiar y parchear (copy-and-patch), con la intención de mejorar el rendimiento en tiempo de ejecución.
Sin embargo, el JIT nunca obtuvo una aprobación formal a largo plazo. Se publicó bajo PEP 744, un PEP informativo que se limitaba a describir la funcionalidad, en lugar de un PEP de Standards Track que habría consolidado su lugar y el compromiso de mantenimiento continuo. Este vacío procedimental dejó su futuro incierto desde el principio.
No fue una reversión motivada por errores; el código funcionaba. En cambio, el proyecto Python permite publicar funcionalidades experimentales sin un compromiso permanente, lo que crea un espacio para la innovación que no carga automáticamente al equipo central con un soporte indefinido. La eliminación del JIT se debe a esta falta de consenso formal, no a un fallo técnico.
El Python Steering Council acabó planteando un ultimátum: conseguir un PEP de Standards Track o el JIT sería eliminado. Esta medida subrayó que, si bien publicar código experimental es una cosa, convencer a la comunidad y a los responsables de comprometer recursos de forma indefinida es un desafío mucho mayor en el desarrollo de código abierto.
El consejo pidió pruebas, no promesas
El consejo directivo de Python, poco impresionado por la introducción informal del JIT, emitió un ultimátum en junio de 2026: presentar y aprobar una propuesta de Standards Track en un plazo de seis meses, o el código del JIT experimental se eliminaría de la rama main. No era una sugerencia; era un plazo estricto para una funcionalidad que había eludido la gobernanza habitual.
En respuesta, Savannah Savannah Ostrowski, Ken Jin y Brandt Bucher presentaron en julio de 2026 PEP 836, acertadamente titulado "JIT Go Brrr: The Path to a Supported JIT Compiler for CPython". La crítica de 10 puntos del consejo fue rápida e implacable. Censuraron que el PEP prestara una atención insuficiente a la seguridad, calificándola de "área desatendida", y descartaron sus proyecciones de rendimiento y de impacto en los usuarios por "excesivamente optimistas".
Quizá el rechazo más contundente fue el relativo a la revisión de compatibilidad propuesta, prevista para la versión candidata de Python 3.17 en agosto de 2028. El consejo consideró este calendario "demasiado, demasiado tarde", lo que subraya su exigencia de garantías inmediatas e inquebrantables. Sin una hoja de ruta convincente, el futuro del JIT parecía cada vez más sombrío, a pesar de su promesa inicial.
Una propuesta prometedora se quedó sin personas
El ultimátum del Python Steering Council pesaba mucho, pero una propuesta prometedora no logró afianzarse. El 19 de octubre de 2026, Savannah Savannah Ostrowski, responsable de versiones de Python 3.16 y 3.17, retiró formalmente PEP 836, la propuesta “JIT Go Brrr” destinada a elevar el JIT al estatus de Standards Track. Su motivo declarado: una evidente falta de “disponibilidad personal para llevar adelante la versión actual”.
Esto no fue una declaración de que los JIT carecieran de valor; todo lo contrario. Savannah Ostrowski y su equipo seguían convencidos del potencial de esta tecnología para mejorar el rendimiento de Python. La retirada reflejó el enorme esfuerzo técnico y político necesario para satisfacer las rigurosas exigencias del consejo, entre ellas abordar las preocupaciones de seguridad y demostrar mejoras de rendimiento más sólidas que las aceleraciones modestas, del 4–12 % de media geométrica, observadas en pruebas de referencia acotadas.
Los comentarios del consejo habían sido contundentes: calificó la seguridad de “área desatendida” y consideró que la revisión de compatibilidad propuesta para agosto de 2028, con Python 3.17, llegaba “demasiado, demasiado tarde”. Sin los recursos dedicados para abordar a fondo estos puntos, PEP 836 no pudo avanzar. Para conocer los antecedentes de la introducción inicial, menos formal, del JIT, consulte PEP 744 – JIT Compilation.
La consecuencia es ahora casi segura: el código del JIT experimental se eliminará de la rama principal de CPython al comienzo del ciclo de desarrollo de Python 3.16. El breve flirteo de Python con un JIT integrado en el árbol de código parece haber terminado, víctima de las realidades del código abierto, donde publicar código suele ser la parte más fácil.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
El verdadero cuello de botella es la titularidad a largo plazo
Fusionar código es el comienzo, no el final, del desarrollo de código abierto. La inminente eliminación del JIT de la rama principal de CPython ilustra una lección crucial: la titularidad va más allá de las confirmaciones iniciales. Los responsables asumen una responsabilidad continua sobre las revisiones de seguridad, los riesgos de compatibilidad, los costes de memoria y el soporte a largo plazo, una carga que el equipo del JIT, a pesar de creer en la tecnología, no pudo sostener.
Este resultado no debe interpretarse como una detención de los esfuerzos de rendimiento de Python. El JIT era una funcionalidad experimental y opcional. Gran parte de las recientes mejoras de velocidad de CPython, incluidas las sustanciales de Python 3.11 y 3.12, provino del intérprete adaptativo especializado, una estrategia de optimización distinta que continúa.
Además, esta decisión no supone el fin del desarrollo de JIT para Python en general. Proyectos alternativos como PyPy, Numba y PyTorch Inductor siguen aprovechando la compilación JIT. Estas soluciones, que abordan cargas de trabajo y entornos de ejecución diferentes, operan al margen del desarrollo central de CPython, lo que demuestra que el concepto de JIT sigue siendo relevante para determinadas aplicaciones Python de alto rendimiento.
Preguntas frecuentes
¿Por qué CPython elimina su JIT experimental?
El JIT carecía de un PEP de Standards Track aprobado, tenía problemas de seguridad y compatibilidad sin resolver, y sus responsables no pudieron comprometer el tiempo necesario para sacar adelante la propuesta.
¿Se eliminó el JIT por tener errores?
No. La decisión se centró en la gobernanza, el mantenimiento a largo plazo, la revisión de seguridad y en si los beneficios esperados justificaban los costes.
¿Cuál era la diferencia entre PEP 744 y PEP 836?
PEP 744 documentaba el JIT experimental, pero era informativo. PEP 836 buscaba la aprobación formal de un JIT con soporte, pero su autora principal lo retiró.
¿Significa esto que Python nunca tendrá un JIT?
No. La decisión se refiere al JIT de la rama principal de CPython; los proyectos independientes y las propuestas futuras todavía pueden recurrir a la compilación JIT.