Python para .Net se levanta de entre los muertos

El desarrollo en IronPython, una implementación de Python que se ejecuta en Common Language Runtime (CLR) del marco .Net, está recibiendo un impulso gracias al proyecto que recientemente cambió de manos a un nuevo líder de desarrollo.

Jeff Hardy, ex desarrollador líder de IronPython, confirmó la transición en la lista de correo de usuarios de Ironpython a principios de este mes. "Por muchas razones, simplemente no tengo el tiempo en este momento para darle a IronPython la atención que se merece", escribió Hardy, "así que estoy entregando el control del proyecto a [otros colaboradores del proyecto] Alex Earl y Benedikt Eggers".

Un Python para .Net y viceversa

IronPython, escrito en C #, no solo está destinado a ejecutar programas estándar de Python. Puede proporcionar a los programadores de Python un puente a las aplicaciones y objetos .Net existentes. Lo mejor de todo es que esos objetos se pueden importar y manejar con la misma sintaxis y modismos que los objetos nativos de Python.

El desarrollo en IronPython, sin duda, se ha ralentizado en los últimos años. La última versión importante fue para Python 2.7.5, a finales de 2014. Python 3 no era compatible con IronPython, un gran inconveniente ya que Python 2 ya no será compatible a partir de 2020, y Python 3 es el sucesor establecido.

En una reunión en el sitio de chat de desarrolladores, Gitter, Earl, Eggers y otros, analizaron los problemas más urgentes que enfrenta el proyecto a medida que avanza: qué hacer con los problemas pendientes de IronPython en CodePlex; qué tipo de programa de lanzamiento implementar; y qué tipo de hoja de ruta diseñar para IronPython 3.

Otro tema que surgió en las discusiones fue cómo implementar el soporte para bibliotecas de Python que usan extensiones C. Si IronPython va a tener la audiencia más amplia posible, esta no es una opción. Muchas de las principales bibliotecas de Python, como Numpy, usan extensiones de C para aumentar la velocidad, y lo ideal sería que funcionen como están en IronPython sin necesidad de volver a compilarlas.

La buena noticia es que ya se ha realizado algo de trabajo en esta área, a saber, Ironclad, un proyecto diseñado para permitir que las extensiones compiladas de CPython funcionen tal cual en IronPython. La mala noticia es que el proyecto no ha tenido mucho trabajo en mucho tiempo y tendrá que ser revisado en profundidad para que sea útil para Python moderno.

De rubíes y GIL

Otro problema que surgió fue cómo lidiar con un proyecto similar manejado por el mismo equipo: IronRuby, que es una implementación .Net de Ruby, como su nombre lo indica. Los dos lenguajes se han desarrollado conjuntamente, ya que se originaron a partir de los mismos esfuerzos dentro de Microsoft en torno al Dynamic Language Runtime, y se mantuvieron muy cerca después de que Microsoft los dividió en esfuerzos impulsados ​​por la comunidad en 2010.

El plan es hacer de IronRuby su propio proyecto para atraer a su propia audiencia de desarrolladores. IronPython 2 también continuará desarrollándose como un proyecto discreto.

El desarrollo futuro de IronPython puede resultar fructífero al proporcionar una forma de cumplir el sueño de muchos años de un tiempo de ejecución de Python rápido y compatible con múltiples núcleos. IronPython no tiene un bloqueo de intérprete global (GIL), una característica de muchas implementaciones de Python a la que se ha culpado de ser una barrera para el alto rendimiento.

Dicho esto, el hecho de que IronPython no tenga GIL no lo hace automáticamente más rápido; algunos puntos de referencia de IronPython son mejores que CPython, pero otros son notablemente peores. Por ahora, simplemente poner al día a IronPython con las ramas actuales de Python, 2 y 3 por igual, debería ser una misión suficiente.