Python elimina su JIT experimental tras retirar el PEP 836

Python elimina su JIT experimental: qué pasó exactamente

El compilador JIT (just-in-time) experimental que CPython incorporó en 2024 junto con Python 3.13 será retirado de la rama principal del proyecto. La confirmación llegó el 19 de octubre, cuando Savannah Ostrowski —release manager de Python 3.16 y 3.17— anunció la retirada del PEP 836, el documento que debía convertir al JIT en una pieza soportada oficialmente del intérprete de referencia.

Para un founder, la lectura es directa: si tu equipo estaba apostando a que Python "gratis" se volviera más rápido por esta vía, ese atajo se cierra dentro del CPython oficial. Y si mantenías builds propios con el JIT activado, hay una migración pendiente en el horizonte.

¿Por qué el consejo de Python frenó el JIT?

La historia viene de lejos. Brandt Bucher, miembro del equipo Faster CPython de Microsoft, fusionó el pull request del JIT en enero de 2024, antes de la salida de Python 3.13. Lo hizo sin un PEP de estándar aprobado: el PEP 744, que documentaba la funcionalidad, era un PEP informativo —es decir, no representa consenso formal para avanzar—. Thomas Wouters, miembro del steering council y release manager de 3.13, fue quien empujó a Bucher a formalizar el trabajo.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

En junio, el steering council pausó todo desarrollo nuevo del JIT en la rama principal hasta que existiera un PEP de estándar que resolviera dudas de mantenimiento, compatibilidad y métricas de éxito. Puso un plazo de seis meses: si no había PEP aceptado, el código del JIT saldría del repositorio principal.

Bucher, Ostrowski y Ken Jin publicaron el PEP 836 ("JIT Go Brrr: The Path to a Supported JIT Compiler for CPython") el 3 de julio. La discusión fue intensa. Una crítica recurrente, planteada por el propio Wouters y por Mark Shannon, fue que el documento parecía contener dos PEPs en uno: los criterios de aceptación por un lado y el plan de implementación por el otro.

El 21 de septiembre el council publicó su posición: el PEP respondía las preguntas planteadas, "aunque algunas con menos convicción que otras", pero no era lo bastante específico sobre planes de soporte y criterios de rendimiento, y era "demasiado optimista" sobre el impacto visible para el usuario. La lista de diez puntos incluía memoria, seguridad, paridad entre plataformas y compatibilidad.

¿Qué tan rápido era realmente el JIT?

Aquí está el dato que explica la frialdad del council. Según InfoWorld, las mejoras de velocidad del JIT eran medibles pero pequeñas, y solo beneficiaban a ciertas clases de programas, como los que tienen bucles ajustados de larga duración.

El propio Bucher ya había sido transparente sobre esto en su charla de PyCon US 2024, recogida por LWN.net: activar el intérprete de micro-ops sin el JIT era alrededor de 20% más lento que el intérprete de bytecode, y el JIT apenas recuperaba ese terreno. El JIT usaba además cerca de 10% más memoria, y su construcción dependía de una versión específica de LLVM.

Esa dependencia sigue siendo un problema abierto. Según LWN.net, compilar el JIT para Python 3.14 requiere LLVM 19 y para Python 3.15 requiere LLVM 21, y ambas versiones ya alcanzaron su fin de vida. Existe un PEP separado, el PEP 774 ("Removing the LLVM requirement for JIT builds"), que eliminaría esa dependencia, pero todavía no fue aceptado.

El PEP 836 se había fijado como meta alcanzar al menos un 20% de mejora en la media geométrica de rendimiento, medida con la suite pyperformance, comparando JIT más Python free-threaded contra free-threaded solo, para la primera beta de Python 3.17. El council consideró que el hito de revisión de compatibilidad —atado al primer release candidate de 3.17, esperado para agosto de 2028— llegaba "demasiado, demasiado tarde" y pedía un proceso continuo desde ya.

¿Qué alternativas quedan para acelerar Python?

El JIT nativo nunca fue el único camino. InfoWorld recuerda que el intérprete adaptativo introducido en Python 3.11 ya entrega mejoras de rendimiento sin obligar a reescribir código, gracias al bytecode especializado por tipos. El equipo de Faster CPython logró que CPython 3.11 fuera 25% más rápido en la mayoría de cargas de trabajo, según la charla de Bucher recogida por LWN.net.

Fuera del árbol oficial hay opciones, todas con letra chica:

PyPy usa un JIT muy optimizado que acelera programas Python en un orden de magnitud o más, pero su desarrollo va por detrás de CPython y ha tenido problemas de rendimiento y compatibilidad con módulos C externos, según InfoWorld.
CinderX, el JIT complementario impulsado por Facebook, funciona como extensión y también se considera experimental.
Numba y PyTorch compile cubren nichos específicos, sobre todo cómputo numérico.

El trabajo en Python free-threaded (sin GIL) continúa por su propio carril, con el PEP 703 como referencia. La dirección técnica que defendían los autores del PEP 836 —soporte free-threaded y un frontend basado en métodos— queda ahora sin dueño dentro del proyecto.

¿Qué significa esto para tu startup?

Primero: no construyas tu roadmap de rendimiento sobre el JIT nativo. Si tu cuello de botella es CPU-bound en Python puro, las palancas siguen siendo las de siempre y no dependen de este proyecto: perfila antes de optimizar, mueve el hot path a una extensión en C, Rust o Go, o evalúa Numba o PyTorch compile si el problema es numérico. El JIT prometía resolver esto sin tocar código, y esa promesa acaba de quedar fuera del CPython oficial.

Segundo: audita tu toolchain si compilas CPython con JIT. Depender de LLVM 19 o 21 —ambas en fin de vida— para builds de producción es deuda técnica que conviene mapear ahora, no cuando toque actualizar la versión de Python. Revisa también si algún servicio interno corre con PYTHON_JIT=1: el JIT se distribuye en los binarios de Windows y macOS, y en algunas distribuciones de Linux como Fedora y Gentoo, siempre desactivado por defecto.

Tercero: trátalo como una señal sobre cómo funciona el open source grande. El council no rechazó la idea del JIT; exigió garantías de mantenimiento, métricas y compatibilidad antes de bendecirlo. Los autores se retiraron argumentando falta de ancho de banda personal. Si tu producto depende de un proyecto comunitario, la pregunta relevante no es solo si la tecnología funciona, sino cuántas personas pueden sostenerla cuando el entusiasmo inicial se agota.

Conclusión

El JIT experimental de CPython muere por falta de un plan de mantenimiento aceptado, no por falta de mérito técnico. Brett Cannon lo resumió con claridad: el trabajo se detiene en el repositorio principal, pero queda abierto a quien quiera continuarlo por fuera. Los autores publicarán la implementación de referencia enlazada desde el PEP retirado.

Para tu startup, la conclusión práctica es que el rendimiento de Python seguirá mejorando por la vía incremental —intérprete adaptativo, free-threading, librerías nativas— y no por un salto mágico del intérprete. Planifica con eso en mente y no con la promesa de una versión futura que todavía no existe.