gh-116167: Permitir deshabilitar el GIL

Alcance del cambio / estado actual

• El cambio proviene del trabajo para hacer que el GIL sea opcional (PEP 703).
• El PR actual requiere compilar CPython con una bandera especial y luego deshabilitar el GIL mediante un interruptor en tiempo de ejecución.
• Esto se presenta explícitamente como un paso temprano, en fase de investigación: se espera que funcione de forma fiable solo para programas sin hilos.
• Las pruebas de asyncio fallan con el GIL deshabilitado; algunos programas simples con hilos “parecen” funcionar, pero no se garantiza que sean seguros.

Rendimiento en un solo hilo vs. múltiples hilos

• Eliminar el GIL permite un paralelismo real en varios núcleos para Python multihilo, útil para cargas de trabajo con muchos hilos (p. ej., ML, investigación).
• Para código de un solo hilo, varios comentaristas señalan una penalización de rendimiento por el bloqueo adicional; PEP 703 cita una ralentización del 5–15%.
• Algunos esperan que más optimizaciones puedan reducir con el tiempo la sobrecarga de las compilaciones nogil para un solo hilo.

Asyncio, hilos y compatibilidad

• Varios comentarios aclaran: la E/S asíncrona y los hilos del sistema operativo son distintos; las roturas actuales están sobre todo en pruebas de asyncio que mezclan hilos y corrutinas.
• Hay confusión en el hilo sobre si “cualquier código con hilos” se rompe; el consenso es: muchos patrones de hilos existentes, especialmente los que implican objetos compartidos, no son seguros en esta versión.

Alternativas a los hilos hoy

• multiprocessing se cita ampliamente como una solución de contorno para tareas limitadas por CPU, pero:
  • En Windows y macOS, la falta de fork / el uso de spawn lo hace lento e incómodo.
  • Grandes huellas de memoria y estructuras de datos compartidas complejas hacen que el paralelismo basado en procesos sea doloroso.
• Bibliotecas como Ray ayudan con múltiples procesos y memoria compartida, pero tienen sus propias limitaciones (por ejemplo, objetos inmutables centrados en arrays).

Impacto en el ecosistema y las extensiones C

• La mayoría de las extensiones nativas (C/C++) dependen implícitamente del GIL para la seguridad en hilos (globales, mutaciones no sincronizadas de listas, etc.).
• El plan es: si una extensión depende del GIL, lo seguirá manteniendo habilitado; a largo plazo, las extensiones deberán actualizarse para ser seguras sin GIL o usar explícitamente el GIL.

Python frente a otros lenguajes y tipado

• Varios comentaristas sostienen que, si hoy quieres “Python + tipos + concurrencia”, Go, Rust, C#, Kotlin, Julia, Nim o lenguajes BEAM pueden ser mejores opciones.
• Otros replican que el ecosistema de Python (NumPy, PyTorch, herramientas de ML/DS) domina, y que nogil junto con comprobadores de tipos modernos (p. ej., mypy, pyright) hacen a Python competitivo para muchos casos de uso.
• Continúa el debate sobre la velocidad de Python y su modelo de tipado frente a lenguajes “modernos”, con el reconocimiento de que Python seguirá siendo más lento, pero aun así puede mejorar de forma significativa.