Código
Desarrollo

Cuatro funciones útiles que no verás en Python

Explicamos por qué algunas características populares que se encuentran en otros lenguajes, incluida la escritura estática, las lambdas multilínea y la compilación JIT nativa, no se pueden utilizar en Python, al menos por ahora.

Candado_00

Python tiene muchas características excelentes —conveniencia, una amplia gama de potentes bibliotecas, una comunidad de usuarios muy útil— pero todavía faltan algunos elementos. Algunas características que se encuentran en otros lenguajes facilitarían ciertos trabajos, pero no van a llegar a Python a corto plazo.

Aquí hay cuatro características del lenguaje comúnmente solicitadas que actualmente no están en las tarjetas para Python. Al menos dos de ellas nunca llegarán, mientras que las otras, en el mejor de los casos, tardarán años en llegar. Veremos qué es lo que bloquea estas características, o qué haría falta para incluirlas en una futura versión de Python.

 

No: una versión compilada de Python con tipado estático

Algunos desarrolladores sueñan con un Python que use escritura estática para compilar a código de máquina nativo. La tipificación flexible es la fuente de gran parte de la lentitud de Python, después de todo, y la tipificación estática pondría fin a eso. El tipado estático también ofrece a los programadores fuertes garantías de lo que pueden esperar de su código. Entonces, ¿cuál es el problema?

Aunque Python tiene sugerencias de tipo, su objetivo es hacer que el lenguaje sea más fácil de analizar estáticamente en el momento de la edición, por medio de las herramientas de linting. Sólo los proyectos de terceros (como pydantic) utilizan sugerencias de tipo en tiempo de ejecución. El tiempo de ejecución de Python por sí mismo no utiliza sugerencias de tipo.

Uno de los objetivos explícitos de la PEP 484, la propuesta de mejora de Python para las sugerencias de tipo, era que las sugerencias de tipo fueran siempre opcionales. "Python seguirá siendo un lenguaje dinámicamente tipado, y los autores no desean hacer nunca obligatorias las sugerencias de tipo, ni siquiera por convención".

Los desarrolladores que realmente quieran una versión de Python con tipado estático pueden recurrir a Cython o a mypyc, pero incluso esos proyectos tienen sus inconvenientes. En el caso de Cython, la mayor mejora de rendimiento proviene del uso de tipos y estructuras C puras, y de la reducción del uso del tiempo de ejecución de Python. Simplemente, es difícil hacer que Python compile más rápido sin sacrificar su dinamismo. Es mucho más fácil tomar las partes que no necesitan dinamismo, separarlas y acelerarlas

 

No: lambdas multilínea

Las expresiones lambda de Python, o funciones anónimas, son deliberadamente limitadas. Sólo permiten una única expresión (esencialmente, cualquier cosa a la derecha del signo = en una operación de asignación) como cuerpo de la función. Los desarrolladores que llegan a Python desde lenguajes como JavaScript, donde las funciones anónimas multilínea son la norma, a menudo piden esta función en Python.

El creador de Python, Guido van Rossum, rechazó hace tiempo la idea de que una lambda fuera algo más que "azúcar sintáctico" para una única expresión. Su posición se resume mejor en un correo electrónico de 2006, en el que discute por qué las lambdas multilínea no son ni serán una cosa en Python:

  • Las lambdas multilínea añadirían poca o ninguna potencia real o expresividad a Python, y tendrían el coste de convertirlo en un lenguaje menos legible. (La legibilidad es una de las principales preocupaciones de Python).
  • No se ha ofrecido ninguna sintaxis utilizable que se integre elegantemente con el resto del diseño de Python, sensible a los espacios en blanco.
  • Se necesita poco esfuerzo para convertir una lambda multilínea en una función completa, que van Rossum recomienda como el caso de uso de una "lambda multilínea", de todos modos.

No hace falta decir que el futuro no parece brillante para las lambdas multilínea en Python.

 

Poco probable: un Python sin GIL

El bloqueo global del intérprete, (Global Interpreter Lock, GIL en sus siglas en inglés), ha sido durante mucho tiempo una espina para los amantes de Python. GIL sincroniza la actividad dentro del tiempo de ejecución de Python para serializar el acceso a los objetos y gestionar el estado global. La desventaja de GIL es que hace que el tiempo de ejecución de Python sea un solo hilo en la práctica. Si quieres un verdadero paralelismo con hilos, necesitas lanzar copias discretas del intérprete de Python y ejecutar hilos separados en cada una. Python sin GIL podría, en teoría, permitir un paralelismo mucho mayor, y por tanto un aumento del rendimiento. Entonces, ¿por qué es poco probable?

Ha habido varias propuestas para eliminar el GIL de Python. La mayoría rompería la compatibilidad con versiones anteriores, o haría que Python fuera más lento en operaciones de un solo hilo, o haría ambas cosas. Una de las propuestas, el proyecto "GILectomy", supuso una gran pérdida de rendimiento. Python 3.x modificó GIL para mejorar su rendimiento básico, pero no lo eliminó para mantener la compatibilidad con versiones anteriores.

Debido a estas preocupaciones, GIL puede ser simplemente una realidad para los usuarios de Python. Pero hay posibilidades de mejorar su rendimiento. Una forma de permitir un mejor paralelismo en el tiempo de ejecución de Python sería ejecutar múltiples intérpretes en un solo proceso. Hacer realidad esta propuesta requeriría cambios significativos en el interior de Python, incluyendo la reelaboración de partes de la API C de Python. Muchos módulos de terceros dependen de la API de C, y también tendrían que ser actualizados.

Una propuesta más reciente, PEP 684, amplía la idea de múltiples intérpretes para que cada subinterpretación utilice su propio GIL. En este caso, el cambio propuesto también permitiría compartir estratégicamente los objetos que deban ser compartidos entre los subinterpretes.

 

Tal vez: un compilador JIT nativo de Python

Una forma probada de hacer que Python sea más rápido manteniendo la querida flexibilidad del lenguaje es utilizar un compilador justo a tiempo, o JIT. La compilación JIT consiste en analizar el código en tiempo de ejecución, en lugar de hacerlo con antelación, y compilarlo selectivamente o en su totalidad a código máquina, basándose en los comportamientos que muestra mientras se ejecuta.

Ya existen JIT para Python. PyPy, el ejemplo más utilizado y mejor desarrollado, destaca por hacer que las aplicaciones de larga duración y estilo servidor ofrezcan un rendimiento mejorado sin modificar el código fuente del programa. Pero, ¿se beneficiaría la versión de referencia de Python, CPython, de tener algún tipo de JIT?

Las recientes iniciativas para hacer que Python sea más rápido, discutidas en la Cumbre del Lenguaje Python de 2021, generaron algunas propuestas en ese sentido. En lugar de implementar un JIT completo en Python, las propuestas actuales implican añadir comportamientos adaptativos al intérprete para una ejecución más rápida en casos especializados comunes. Puede haber espacio para otros tipos de especialización de tipo JIT en el futuro, como generar código máquina para rutas de código verdaderamente rápidas. Pero el plan a corto plazo es realizar mejoras que amplíen el intérprete existente en lugar de sustituirlo.



TE PUEDE INTERESAR...

Nuevo número de nuestra revista de canal 
 
DealerWorld Digital

 

Cobertura de nuestros encuentros

 

Documentos ComputerWorld



Forma parte de nuestra comunidad

 

¿Te interesan nuestras conferencias?