El proyecto de comprobación de tipo estático de Mypy para Python está explorando formas en que podría ayudar con la compilación sin esfuerzo de Python en C o lenguaje de máquina.
Es el sueño de todos los programadores profesionales de Python: tomar una aplicación Python existente, ejecutarla a través de un compilador y generar código de alta velocidad y plataforma nativa respetando la naturaleza dinámica de Python.
En teoría, eso es posible hacerlo ahora, o algo así. El problema es que cada trayectoria disponible está plagada de limitaciones.
Tienes que modificar la fuente de manera no estándar (Cython), usar en tiempo de ejecución los reemplazos que es muchas veces mayor que el normal y tiene sus propias limitaciones (PyPy), o trabajar con herramientas que son todavía enormemente inestables y experimentales (Nuitka).
Ahora el equipo de desarrollo de Mypy, la sintaxis optativa de escribir de forma estática para Python que se ha convertido en un problema para el estándar para el lenguaje, está analizando la posibilidad de usar Mypy para generar código que se puede compilar a un binario.
La discusión que surgió alrededor de la idea: Las herramientas para compilar Python necesitan hacer el código de Python más rápido sin complicar también las cosas para los desarrolladores.
Exactamente mi tipo
La idea de usar Mypy como un paso hacia una versión compilada estáticamente de Python ha estado dando vueltas desde que surgió la sintaxis -más aún desde que Mypy fue aceptado como un estándar de Python.
El creador de Python, Guido van Rossum, ha declarado anteriormente que la introducción de Mypy en Python no fue concebida como un preludio para hacer que Python esté escrito de forma estática.
Uno de los mayores beneficios de Python siempre ha sido su dinamismo; cualquier cosa que haga a Python menos dinámico por defecto no es un triunfo.
«La filosofía básica del lenguaje no va a cambiar», dijo van Rossum. Mypy permite que los linters de código y los controladores garanticen mejor la calidad del código Python, al mismo tiempo que se preserva el dinamismo.
Dicho esto, van Rossum no se opone a la idea de las implementaciones de Python para que se compile estáticamente.
Para ello, la sintaxis de Mypy podría utilizarse como base para una representación intermedia o versión transpiled de Python que alimente a un compilador.
Python como idioma seguiría siendo dinámico; esto da una nueva ruta para volverse estática. (Van Rossum también ha dado los pulgares para explorar estrategias para Mypy para ayudar con la compilación estática).
Lo que sale por el otro extremo
La discusión dentro del equipo de Mypy todavía está en las primeras etapas, pero algunos puntos claves han surgido en el debate. Si esto se hizo, los desarrolladores de Mypy argumentan, ¿qué tipo de código se produciría?
Un método implica lo que se ha descrito como PyIR: una representación intermedia para el código Python, o IR, que se inspira en el proyecto WebAssembly.
Otra posibilidad, que potencialmente implica mucho menos reinventar desde cero, sería aprovechar el proyecto Cython.
Cython permite que el código existente de Python se compile a C, a menudo con dramáticas aceleraciones, anotando código Python con marcado para indicar el tipo de variable estática.
Pero el marcado de Cython no se parece en nada a Mypy o C. Es un subdialecto idiosincrásico de Python.
Sin embargo, no es mucha la diferencia para imaginar cómo el código Python anotado por Mypy podría convertirse en Cython (y por tanto en C).
Tan elegante como esa solución suena, también está lleno de inconvenientes.
Por ejemplo, algunas anotaciones de tipo de alto nivel en Mypy no se correlacionan precisamente con algunos tipos de Cython cercanos a la máquina.
Los desarrolladores tendrían que añadir más anotaciones de tipo o el compilador tendría que hacer conjeturas contextuales sobre la escritura.
La discusión de GitHub también expuso el problema de ser forzado a elegir entre los tipos que ayudan a la productividad del programador (el fuerte de Python) o el tipado que es útil al compilador (la especialidad de C).
Cython se utiliza principalmente para optimizar módulos individuales y funciones donde la velocidad es crítica – «hot spots» – en lugar de programas enteros, por lo que los desarrolladores sólo necesitan proporcionar anotación de tipo a las partes de la aplicación que lo necesitan.
Por el contrario, la discusión de Mypy toma la idea más holística de alimentar al compilador todo el árbol fuente de Python y recuperar un único producto unificado.
Entregando lo bueno
Si ese es el objetivo más grande con un compilador estático para Python, el problema real puede no ser con la compilación estática, sino con cómo la compilación estática puede ser parte de una cadena de herramientas de extremo a extremo para el lenguaje.
Toolchains en lenguajes como C/C++ — así como derivados como Rust, Go y Nim — producen un binario sin la necesidad de un runtime externo. Python ha sido durante mucho tiempo un lenguaje interpretado, por lo que no tiene tradición nativa, aparte de las herramientas de empaquetado (no compilación) de terceros como PyInstaller.
Si Python obtuvo tales herramientas, es probable que no procedan del proceso de desarrollo básico del lenguaj, ya que el lenguaje es en primer lugar dinámico e interpretado.
Pero hay claramente interés en tener más toolchains para Python que produzcan de forma fiable ejecutables nativos en las distintas plataformas o al menos un código de nivel inferior que se puede compilar en el mismo.
Como dijo el comentarista wtpayne en la discusión de GitHub, «Estoy interesado en construir una cinta transportadora suave y continua que tome ideas (algoritmos) desde el inicio hasta la producción».