Informe de la Cumbre Language Summit de 2011

La Language Summit de este año tuvo lugar el jueves 10 de marzo en Atlanta, el día anterior al comienzo de las conferencias de PyCon. Asistieron representantes de las implementaciones CPython, PyPy, Jython, IronPython, y Parrot; desarrolladores de los paquetes para Fedora, Ubuntu, y Debian; desarrolladores del proyecto Twisted , y muchos otros.

Blog de desarrollo

Uno de los primeros asuntos tratados fue este mismo blog, iniciado por el Responsable de Comunicaciones de la PSF, Doug Hellmann. La lista de correo de python-dev tiene mucho tráfico, y a menudo muy intenso, por lo que nace este blog. Pretende ser una forma más sencilla para los usuarios de seguir las novedades del desarrollo. Pensamos cubrir los PEP, todas las decisiones importantes, nuevas características y bugs críticos; y se incluirá una cobertura informal de qué está pasando en el proceso de desarrollo.

La publicación en el blog está abierta a todas las implementaciones de Python. Por ejemplo, aunque PyPy ya tiene su propio blog activo, estaremos encantados de que publiquen aquí también sus novedades. Una discusión paralela conduce a implementaciones alternativas, también mencionadas en la página de descargas de python.org. Las nuevas versiones liberadas también serán recogidas como nuevos elementos en la página principal de python.org

Advertencias de compatibilidad

Con 3.2 introducimos ResourceWarning para que los usuarios pudieran encontrar áreas de código dependientes del recuento de referencias de CPython. La advertencia no sólo ayuda a los usuarios a escribir un mejor código, sino que además les permite escribir código más portable entre diferentes máquinas virtuales. Para mayor compatibilidad entre implementaciones, se sugirió un nuevo tipo de aviso: CompatibilityWarning

La idea surgió gracias a un bug en CPython recientemente archivado, encontrado por los desarrolladores de PyPy (Issue #11455 ) Se explica una situación donde CPython permite al usuario crear un tipo con claves no de cadena en su __dict, que al menos PyPy y Jython no soportan. Idealmente, los usuarios podrían activar una advertencia para detectar estos casos, tal y como hacen con ResourceWarning.

Biblioteca Estándar independiente

Ahora que la transición del código de Cpython de Subversion a Mercurial ha sido completada, ha resurgido la idea de separar la biblioteca estándar a su propio repositorio. Los desarrolladores de las implementaciones alternativas están muy interesados, ya que esto simplificaría enromemente su proceso de desarrollo. A día de hoy, toman una instantánea de CPython y le aplican cualquier implementación específica, reemplazan algunas extensiones en C con versiones de Python puro, etc.

La conversión tendrá que ser definida en un próximo PEP. Uno de los puntos de la discusión es cómo se implementará el control de versiones. Dado que la biblioteca vivirá fuera de cualquiera de las implementaciones, es probable que sea controlada por sí misma, y las pruebas necesitarán considerar también la versión.

Otra asunto a tratar en la separación de la biblioteca es la implementación en Python puro o sus equivalentes en C. Maciej Fijalkowski, del proyecto PyPy, mencionó que con el tiempo, algunos módulos han tenido pequeñas diferencias entre sus versiones en C y Python. Mientras la discusión sobre esta separación continúa, el equipo ha sugerido un enfoque más estricto a los cambios en dichos módulos para no penalizar el uso de uno u otro. Se prefirió, además, la implementación en Python, reservando las versiones en C sólo para los casos en los que se obtenga una mejora en el rendimiento.

Página de logros de rendimiento

El Speed Center de PyPy ha hecho un gran trabajo mostrando los resultados del rendimiento de PyPy, y sugirió cierta discusión sobre si alojar un sitio similar en python.org, posiblemente performance.python.org, para todas las máquinas virtuales que tomen parte. Además de los logros de rendimiento, se deberán considerar cosas como uso de memoria, tests pasados y compatibilidad del lenguage. Actualmente se compara PyPy y CPython, por lo que se necesitará cierto trabajo para adaptar la infraestructura para trabajar con otras implementaciones.

El nuevo Speed Center podría vivir en el Laboratorio de Código Abierto en la Oregon State University (Allison Randal pertenece a su junta directiva). Jesse Noller mencionó el esfuerzo que supone obtener máquinas de alto rendimiento para instalar. ¡Las donaciones son bienvenidas!

Si tú o tu organización estáis interesados en donar para esta causa, u otras, por favor contactad con la Python Software Foundation, y visitad nuestra página de donaciones.

Levantamiento de la moratoria

Con el comienzo del desarrollo de CPython 3.3, la moratoria en los cambios del lenguaje se ha levantado. Aunque no hay límites definidos, se espera que los cambios sean conservativos. Al intentar reducir el ritmo de cambio, permitimos que las implementaciones alternativas se pongan al día. Si bien ninguna logró llegar a la familia 3.x, gracias a la moratoria, PyPy y IronPython alcanzaron recientemente la compatibilidad con 2.7, e IronPython ha comenzado su andadura hacia 3.x.

En cuanto a los cambios que se esperan en 3.3, esperamos que el PEP 380 sea aceptado. Este PEP introduce una nueva sintaxis para yield from <expr>, permitiendo a un generador devolver mediante un yield otro generador. Aparte de esto, no se esperan más cambios en el futuro cercano.

Atributos de las excepciones

El siguiente tema fue una rápida discusión sobre las excepciones. Éstas deberían proporcionar mejores atributos, en lugar de forzar a los usuarios a confiar en mensajes en strings. Por ejemplo, en un ImportError, sería útil tener fácil acceso al import que ha fallado, en lugar de tener que analizarlo para identificarlo.

La implementación se basará probablemente en un argumento palabra clave cuando se inicialize el objeto excepción. Actualmente existe un parche para el caso del ImportError.

Acuerdos de contribución

Los acuerdos de contribución fueron también mencionados, y algunos acuerdos electrónicos están en marcha. El acuerdo de contribución individual de Google fue una de las múltiples inspiraciones sobre el funcionamiento del nuevo sistema. El asunto ha sido extensamente discutido, y mucha gente está deseando una resolución en este área. Adicionalmente, se está investigando para asegurar que cualquier un acuerdo electrónico sea válido en jurisdicciones fuera de EE.UU.

Google Summer of Code

Martin von Lšwis dedicó un minuto para introducir otro año del Google Summer of Code, bajo el paraguas de la PSF. Se anima a los desarrolladores a actuar no sólo como maestros, sino también proponiendo proyectos en los que trabajar a los estudiantes (y recordar que sugerir un proyecto no implica que lo vayas a supervisar tú). Si estás interesado en ayudar en cualquier forma, visita la convocatoria para proyectos y mentores. de la PSF.

Distutils

Le llegó el turno a Distutils2, y Tarek ZiadŽ mencionó que su objetivo a corto plazo es terminar la migración a Python 3 y prepararlo para la consiguiente fusión de nuevo en la biblioteca estándar de Python. Adicionalmente, con la nueva fusión viene un nuevo nombre: packaging. El equipo de packaging también planea proeveer un paquete independiente, todavía llamado Distutils2, soportando desde Python 2.4 hasta 3.2.

El resultado del sprint de packaging, que fue uno de los mayores grupos de la PyCon, fue muy bueno. Sus resultados están en Bitbucket, esperando su fusión con la biblioteca estándar.

El futuro de las máquinas virtuales alternativas

IronPython comentó sus planes de futuro, y el lanzamiento de la 3.x está próximo. Anunciaron el de su versión 2.7.0 en la PyCon, su primera versión basada en la comunidad desde que el proyecto fue cedido por Microsoft, y comenzarán el trabajo hacia la 3.x en los siguientes meses.

Jython publicó recientemente la versión 2.5.2, y ha comenzado a planear la 2.6. Algunos han sugerido que salten a la 2.7, ya que las diferencias entre ambas no son grandes; pero el salto podría retrasar la primera liberación. La frase "libera pronto, libera a menudo" fue citada en la charla. Podrían ser capaces de dar el salto de la 2.6 a 3.x y considerar las diferencias entre 2.6 y 2.7 después.

Financiación del desarrollo

Aparte de los planes para la 3.x, está el asunto de la financiación del desarrollo y cómo facilitar el que alguna de las implementaciones alternativas alcance la serie 3.x. En cualquier caso, se debe hacer una propuesta a la PSF antes de que nada pueda ser discutido. Aquellos interesados en recibir becas por su trabajo, deberían contactar la Junta de la PSF.

Meta de Python

Jim Fulton comenzó una discusión sobre lo que él llamó la "meta" de Python. En su experiencia desplegando aplicaciones de Python, se ha encontrado con que el sistema es impredecible y dificil de manejar. Con expertos en empaquetado de Fedora y Ubuntu/Debian a mano, fuimos capaces de echar una mirada crítica a por qué las cosas son como son.

En Fedora, la instalación básica de Python está basada en el Live CD, por lo que es una versión mínima con pocas dependencias, los mínimos exigibles para que el sistema pueda correr. Otras diferencias que se ven son la eliminación de módulos de la biblioteca estándar, como distutils, o que la distribución incluye bibliotecas desfasadas.

No parece que a día de hoy haya una solución clara, pero las partes implicadas continuarán trabajando en el problema.

Características de la 3.3

Srgieron algunas ideas para la 3.3, incluyendo dos PEP. El PEP 382, acerca de los espacios de nombres en paquetes debería aparecer en algún punto del ciclo. También fue mencionado durante la discusión de la fusión de distutils.

El PEP 393, que define una representación flexible de las strings, fue también discutido, y despertó el interés de algunos estudiantes como proyecto GSoC. Junto con las implementaciones, se necesitará dedicar cierto esfuerzo para caracterizar el rendimiento y uso de memoria para ver si pueden ser aceptados.

Unladen Swallow

Unladen Swallow (golondrina sin carga) está a día de hoy en un estado de "reposo" y no se incluirá en CPython 3.3. Para progresar, necesitaremos la ayuda de más desarrolladores, ya que los expertos actuales son insuficientes para realizar el trabajo. Durante la discusión, se comentó de nuevo que si la financiación es lo que empujaría Undaden Swallow al siguiente nivel, los interesados deberían contactar con la PSF.

Aunque Unladen Swallow esté en estado de reposo y su futuro sea incierto, el proyecto ha proporcionado múltiples beneficios a Python y a la comunidad de código abierto en general. Por ejemplo, el conjunto de herramientas de pruebas de rendimiento usado por Unladen Swallow es muy útil para probar implementaciones alternativas. Además, desarrolladores de Unladen Swallow han contribuído a LLVM y Clang.

Otras dos ideas de rendimiento fueron discutidas brevemente, incluyendo la propuesta de Dave Malcom de incluir el código de funciones en el propio cuerpo (inlining). Martin von Lšwis comentó que está trabajando en un módulo de compilación al vuelo, aunque los desarrolladores de PyPy expresaron su escepticismo acerca de la efectividad de este tipo de sistemas.

Pavimentando el camino a los frameworks asíncronos

Al final del día hubo una discusión acerca del nivel de integración de Twisted en la biblioteca estándar. La idea principal es que existe una alternativa a asyncore que permite una una transición más fácil a Twisted o otros frameworks de programación asíncronos.

El proceso se llevará a cabo en un PEP, que algunos han sugerido servirá para un propósito similar a la WSGI, pero para bucles de eventos asíncronos. Junto con los autores del PEP, el proyecto Twisted y otros necesitarán esforzarse en asegurarse de que todo el mundo está en el mismo lado.

Más información

Para más información, lee las notas de Nick Coghlan (desarrollador de CPython) y lo más destacado (en inglés).