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).
No hay comentarios:
Publicar un comentario