El JIT experimental de Python será eliminado
Los desarrolladores principales de Python han decidido eliminar el compilador experimental just-in-time (JIT) de CPython, citando una falta de claridad sobre el mantenimiento a largo plazo, mejoras modestas en el mundo real y la complejidad que añade a un entorno de ejecución ampliamente usado y sensible a la seguridad. Los comentaristas se dividen entre ver esto como una gobernanza saludable que protege la estabilidad y la compatibilidad de herramientas, y verlo como una burocracia sofocante que hace casi imposible incorporar trabajo ambicioso de rendimiento en la implementación principal. Muchos señalan alternativas como PyPy, GraalPy, Cython, Numba o reescrituras completas en lenguajes más rápidos, al tiempo que lamentan que las peculiaridades del ecosistema de Python y de su API C dificulten de forma inusual combinar la popularidad del lenguaje con un rendimiento de vanguardia.
Reacción general a eliminar el JIT
- Muchos expresan decepción; esperaban que el JIT acelerara de forma significativa el “Python puro” y redujera la necesidad de reescrituras en Cython/Rust.
- Otros ven la decisión como razonable dado que las mejoras de rendimiento eran modestas (a menudo citadas en torno a ~10%) frente a una gran complejidad y carga de mantenimiento.
- Algunos lo ven como otro intento fallido de JIT para Python (después de Psyco, Unladen Swallow, etc.), lo que refuerza el pesimismo sobre que CPython llegue algún día a tener un JIT sólido dentro del árbol.
Proceso, gobernanza y “burocracia”
- Un bando sostiene que el proceso de comité y los estrictos requisitos de los PEP acabaron con un experimento por lo demás prometedor, citando requisitos “veneno” como soporte amplio para herramientas y métricas de éxito.
- Otro bando argumenta que el proceso funcionó como debía: una vez que algo vive en
main, debe tener un alcance claro, un plan de mantenimiento y una historia de compatibilidad; los experimentos abiertos no pertenecen al núcleo de un lenguaje de infraestructura global. - Hay desacuerdo sobre si esto es “burocracia” o simplemente una gobernanza necesaria para un ecosistema maduro.
Desafíos técnicos de un JIT para Python
- Se cita la extrema dinamismo de Python como problema central:
__dict__, reasignación de__class__, monkey-patching, metaprogramación, reescritura de bytecode en pytest, extensiones en C y APIs de introspección complican la optimización. - Algunos sostienen que estas dificultades no son fundamentalmente mayores que las semánticas de JavaScript o Ruby, y que JITs exitosos (V8, LuaJIT, PyPy, GraalPy) demuestran que es viable con suficiente inversión.
- Otros señalan que la API C de CPython filtra detalles de implementación, lo que hace especialmente arriesgados cambios profundos como un JIT y la eliminación del GIL.
Rendimiento actual y alternativas existentes
- Opciones mencionadas con frecuencia: extensiones en C, Cython, Numba, mypyc, PyPy, GraalPy, Rust (vía PyO3) y reescrituras en Go.
- Críticas: están fragmentadas, y cada una tiene limitaciones (retraso respecto a versiones, problemas con la API C, subconjuntos restringidos, complejidad de despliegue). Muchos siguen queriendo “simplemente un CPython más rápido”.
- Algunos argumentan que Python ha alcanzado límites prácticos: si el rendimiento es un requisito central, la respuesta es reescribir las partes calientes o sistemas completos en lenguajes más rápidos, posiblemente con ayuda de IA.
Preocupaciones de seguridad y fiabilidad
- Algunos apoyan evitar un JIT por el historial de seguridad en motores de JS y PHP; valoran la VM de bytecode más simple de CPython y su recuento relativamente bajo de CVE.
- Otros responden que Python rara vez ejecuta código no confiable, así que los riesgos específicos de un JIT son menos convincentes que los problemas de seguridad ya introducidos por las extensiones en C.
Direcciones alternativas y subconjuntos
- Varios sugieren que un subconjunto más estricto y tipado de Python con AOT/JIT (p. ej., “Static Python”, algo estilo Mojo, o CinderX) puede ser la única vía sostenible hacia grandes mejoras de velocidad.
- Existe escepticismo de que tal subconjunto pueda estandarizarse sin una enorme discusión interminable sobre detalles, dada la cultura de Python y sus características dinámicas existentes.