Python es un lenguaje de alto nivel de programación

Hace poco se dio a conocer la noticia de que el Comité Directivo del Proyecto Python ha anunciado su deseo de aprobar la propuesta de la extensión del lenguaje Python «PEP-0703″, hacer que el bloqueo de intérprete global sea opcional en CPython y que básicamente define la incorporación del modo de compilación de CPython sin Global Interpreter Lock (GIL).

PEP-0703 define dejar de utilizar GIL de manera predeterminada, pero agregar la opción de compilación «–sin-gil» para deshabilitarlo. Como tal se busca que el nuevo modo resuelva el problema con la paralelización de operaciones en sistemas de múltiples núcleos, causado por el hecho de que el bloqueo global no permite el acceso paralelo a objetos compartidos desde diferentes subprocesos.

Se menciona que a largo plazo (después de 5 años), está previsto que el intérprete se cambie por defecto a solo en el modo sin bloqueo global, mientras que al mismo tiempo dejará de admitir la compilación con GIL.

Gracias a todos por responder a la encuesta sobre la propuesta de no-GIL . Está claro que el sentimiento general es positivo, tanto para la idea general como para el PEP 703 en particular. El Consejo Directivo también es en gran medida positivo en ambos. Tenemos la intención de aceptar PEP 703, aunque todavía estamos trabajando en los detalles de aceptación.

Como lo hemos hecho algunas veces en el pasado, queremos comunicar nuestra intención de aceptar el PEP junto con nuestro pensamiento actual sobre los detalles relacionados con la aceptación.

Ademas de ello, se menciona que los cambios que se planean realizar se llevaran a cabo en tres etapas, la cuales son a corto, mediano y largo plazo. Ya que en la primera etapa, deshabilitar GIL de forma predeterminada no es práctico debido a la sobrecarga asociada con los cambios en el recolector de basura, el sistema de administración de memoria y las primitivas para organizar bloqueos. Por ejemplo, debido al uso del conteo de referencias para el aislamiento de subprocesos, hay una disminución en el rendimiento de los scripts de un solo subproceso (en el conjunto de pruebas de pyperformance en un 10 %). Al mismo tiempo, puede ser necesario deshabilitar el GIL en computación científica, para lo cual la falta de paralelización es un problema más serio que la velocidad lineal de ejecución del código.

En la segunda etapa básicamente se esperará la confirmación y que se cuente con el suficiente apoyo de la comunidad para que el uso de «no-GIL sea viable» y asegurarse de que la compilación sin GIL sea compatible pero no predeterminada.

En la ultima etapa, no-GIL ya será el valor predeterminado y se eliminará cualquier vestigio de GIL (sin romper innecesariamente la compatibilidad con versiones anteriores).

Se observa que el trabajo para alejarse de GIL se realizará con mucho cuidado para no repetir el error que ocurrió al promocionar Python 3: una compilación sin GIL tendrá que asegurarse de mantener la compatibilidad con versiones anteriores de Python y cualquier cambio en el código de terceros necesario para trabajar en compilaciones que no sean GIL también debería funcionar en compilaciones GIL.

No hay planes para volver a numerar las versiones a Python 4 para compilaciones que no sean GIL, ya que mantendrán la compatibilidad con ABI.

A lo largo del proceso, nosotros (los desarrolladores principales, no solo el SC) necesitaremos volver a evaluar el progreso y los plazos sugeridos. No queremos que esto se convierta en otra lucha de compatibilidad con versiones anteriores de diez años, y queremos poder cancelar PEP 703 y encontrar otra solución si parece que se vuelve problemático, por lo que debemos verificar regularmente que el trabajo continuo es vale la pena.

Esperamos que esto brinde cierta claridad sobre el futuro del PEP mientras trabajamos en los detalles exactos de aceptación. El SC trabajará para finalizar la aceptación en las próximas semanas.

Antes de la transición completa a las compilaciones que no son GIL, se planea lograr un soporte completo de la comunidad para estas compilaciones, así como proporcionar API de C y API de Python adicionales para habilitar subprocesos múltiples seguros en el código existente.

Finalmente como ya se menciono se prevé que la transición a la tercera etapa pueda ocurrir al menos en 5 años y la fecha probable para PEP-0703 es el lanzamiento de Python 3.13, programado para el próximo otoño.

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.