La llegada de Python 3.13 en octubre de 2024 trajo un cambio que la comunidad llevaba más de una década discutiendo. Ahora se puede ejecutar el intérprete sin el Global Interpreter Lock, conocido como GIL. Casi un año después del lanzamiento hay suficientes informes de uso real para separar la promesa del matiz. El resultado es interesante y, como suele pasar, más complicado de lo que los titulares sugirieron.

Puntos clave

  • El PEP 703 hace el GIL opcional en tiempo de compilación; el binario estándar sigue con GIL, el binario python3.13t lo elimina.

  • Las cargas que más ganan son las orquestadoras: hilos en paralelo haciendo llamadas HTTP, parseando JSON, transformando datos en Python puro.

  • Cargas puramente en NumPy/SciPy o similares que ya liberaban el GIL internamente no notan diferencia significativa.

  • El coste oculto: en la build free-threading de 3.13, el rendimiento single-thread cae en torno a un 40% respecto al mismo Python 3.13 con GIL, según la documentación oficial.

  • La cobertura del ecosistema de PyPI sigue siendo parcial; esperar a Python 3.14 (octubre 2025) para producción es una opción prudente.

Qué es exactamente free-threading en 3.13

El PEP 703[1], aceptado por el comité directivo de Python en 2023, propuso hacer el GIL opcional en tiempo de compilación. Python 3.13 incluye esta capacidad como construcción experimental, indicada con el sufijo t en el binario: python3.13t frente a python3.13. El binario estándar sigue teniendo GIL porque su eliminación introduce cambios profundos en la gestión de memoria del intérprete que no pueden activarse y desactivarse dinámicamente sin coste.

La diferencia de fondo es que el binario con GIL serializa todo el bytecode Python a un solo hilo dentro del proceso. Esto simplifica la implementación del intérprete y garantiza que las estructuras de datos internas no se corrompan. La contrapartida, conocida desde hace años, es que un proceso Python no puede usar más de un núcleo en paralelo para código puro. Necesita multiprocessing (con sus propios costes de memoria y serialización) o librerías que liberan el GIL en código nativo, como NumPy.

En el binario sin GIL de 3.13, los hilos Python ejecutan bytecode en paralelo de verdad. Para cargas de trabajo donde cada hilo hace trabajo independiente en Python puro, la ganancia puede ser lineal con el número de núcleos.

Qué gana de verdad y qué no

En pruebas publicadas por Meta[2] y por el tracker comunitario de compatibilidad free-threading[3], las cargas que más ganan son las de tipo orquestador. Esas cargas lanzan hilos en paralelo haciendo llamadas HTTP, parseando JSON, transformando estructuras de datos medianas. En esos casos, los benchmarks compartidos por la comunidad reportan entre dos y seis veces más rendimiento con cuatro u ocho núcleos.

Las cargas que apenas ganan:

  • Cálculo intensivo en Python puro que ya estaba en NumPy, SciPy o bindings a C (esas librerías ya liberaban el GIL).

  • Cargas web con Django o Flask sobre WSGI donde los trabajadores ya eran procesos, no hilos.

  • Scripts CLI de un solo hilo, donde no hay paralelismo que explotar.

Hay un grupo que sí se beneficia con trabajo adicional: aplicaciones que hoy usan multiprocessing para rodear el GIL pueden volver a hilos, ahorrando la serialización y la memoria duplicada. El ahorro puede ser significativo en cargas con estructuras de datos grandes compartidas entre trabajadores. Volver de procesos a hilos requiere rediseñar cómo se comparte el estado, que es más fácil con hilos pero no trivial.

El coste oculto: velocidad en un solo hilo

Free-threading no es gratis. La implementación requiere:

  • Recuento de referencias atómico.

  • Candados adicionales en estructuras internas del intérprete.

  • Cambios en el recolector de basura.

El coste aproximado, documentado por el propio proyecto Python[4], es una reducción del rendimiento single-thread de en torno al 40% sobre la suite pyperformance. La comparación es con el mismo Python 3.13 con GIL. El objetivo declarado para próximas versiones es bajarlo al 10% o menos. Para cargas que no paralelizan y que corren hilo único, este es un precio que se paga sin ganancia.

De ahí que Python 3.13 haga free-threading opcional y no por defecto. Esta decisión de diseño es razonable: no obliga a nadie a pagar el coste si no lo va a rentabilizar. Pero tiene una implicación operativa: los paquetes binarios en PyPI tienen que ofrecer ruedas para ambos ABI (cpython313 y cpython313t), lo que duplica el trabajo de mantenimiento. A mediados de 2025 la cobertura del ecosistema sigue siendo parcial.

Compatibilidad del ecosistema

Hay un problema más sutil: mucho código C que interactúa con Python asumía la serialización implícita del GIL. Una extensión C que guardaba estado en variables globales, o que modificaba estructuras Python sin tomar candados explícitos, funcionaba por accidente gracias al GIL. En free-threading ese código se corrompe silenciosamente. La lista de extensiones que han tenido que arreglar bugs ocultos incluye nombres conocidos.

El consejo conservador es esperar a que las dependencias críticas de la aplicación declaren explícitamente compatibilidad con free-threading antes de desplegar en producción. Esperar a Python 3.14, previsto para octubre de 2025, donde está anunciada la promoción de free-threading de experimental a soportado, es una opción prudente.

La discusión de rendimiento de Python conecta con las optimizaciones que describimos en Python 3.12 aceleración. También con los patrones de concurrencia que aparecen en servicios de streaming como los analizados en Kafka para streaming de eventos.

Cómo probarlo en un entorno real

La forma más segura de empezar:

  • Usar los contenedores oficiales de Python 3.13 con la etiqueta freethreading.

  • Levantar la aplicación bajo ese intérprete y ejecutar las pruebas habituales.

  • Medir con la misma carga en python3.13 con GIL activado como línea base.

  • La variable de entorno PYTHON_GIL permite cambiar el comportamiento en tiempo de arranque para comparar limpiamente.

Medir con una carga representativa, no con un microbenchmark aislado, es la diferencia entre tomar una decisión útil y una equivocada.

Mi lectura

Free-threading vale la pena ahora si la aplicación cumple tres condiciones:

  • Tiene cargas que hoy sufren contención por GIL.

  • Sus dependencias están al día.

  • Hay tiempo para observar en producción con capacidad de rollback.

Si falta alguna de las tres, esperar a Python 3.14 o incluso 3.15 es perfectamente razonable.

Para aplicaciones nuevas que van a arrancar en 2026 con horizonte largo, tiene sentido diseñar asumiendo que free-threading va a ser mayoritario dentro de un par de años. En la práctica: elegir librerías compatibles y usar patrones de concurrencia con hilos en vez de multiprocessing. Para aplicaciones existentes y estables, la actitud correcta es medir antes de decidir y mantener un plan de vuelta atrás. El ecosistema todavía está madurando y las sorpresas están en las dependencias, no en el intérprete.

Este artículo también está disponible en inglés: Python 3.13 with optional GIL: what it means for teams.

Fuentes:

  1. PEP 703: Making the Global Interpreter Lock Optional in CPython[1]
  2. Python 3.13: soporte experimental para free threading (documentación oficial)[4]
  3. Meta Engineering: Enhancing the Python ecosystem with type checking and free threading[2]
  4. Python Free-Threading Guide, tracker comunitario de compatibilidad[3]
  5. PEP 779: Criteria for supported status for free-threaded Python[5]

Preguntas frecuentes

¿Cuánto rendimiento pierdo en un solo hilo con la build free-threading de Python 3.13?

En torno a un 40 % sobre la suite pyperformance, comparado con el mismo Python 3.13 con GIL, según la documentación oficial del proyecto. El objetivo declarado para próximas versiones es bajarlo al 10 % o menos. El coste viene del recuento de referencias atómico, candados adicionales en el intérprete y cambios en el recolector de basura. Para cargas que no paralelizan, como scripts CLI de un solo hilo, es un precio sin ganancia, y por eso free-threading es opcional y no el default.

¿Qué tipo de aplicaciones ganan de verdad al quitar el GIL?

Las de tipo orquestador: lanzan hilos en paralelo para hacer llamadas HTTP, parsear JSON o transformar estructuras de datos en Python puro. Los benchmarks compartidos por la comunidad reportan entre dos y seis veces más rendimiento con cuatro u ocho núcleos. No ganan las cargas ya asentadas en NumPy, SciPy o bindings a C (ya liberaban el GIL), Django o Flask sobre WSGI con trabajadores por proceso ni los scripts de un solo hilo. Quien usa multiprocessing para rodear el GIL puede volver a hilos y ahorrar memoria y serialización.

¿Cómo pruebo free-threading en mi aplicación sin arriesgar producción?

Usa los contenedores oficiales de Python 3.13 con la etiqueta freethreading y levanta la aplicación bajo python3.13t. Ejecuta las pruebas habituales y mide con la misma carga sobre python3.13 con GIL como línea base. La variable de entorno PYTHON_GIL permite cambiar el comportamiento en el arranque para comparar limpiamente. Mide con una carga representativa, no con un microbenchmark, y comprueba que tus dependencias críticas declaran compatibilidad, porque las extensiones C que asumían el GIL se corrompen silenciosamente.

Fuentes

  1. PEP 703
  2. Meta
  3. tracker comunitario de compatibilidad free-threading
  4. documentado por el propio proyecto Python
  5. PEP 779: Criteria for supported status for free-threaded Python