Conoce al equipo: Brian Curtin

Artículo original: Meet the Team: Brian Curtin
Esta entrada es una más de la serie "Conoce al equipo", la cual está pensada como una pequeña introducción al equipo de desarrollo del núcleo de Python.

Nombre:	Brian Curtin
Lugar:	Chicago, IL
Página Web:	http://blog.briancurtin.com/

¿Cuánto tiempo llevas usando Python?
Lo llevo usando cada día desde hace 6 años. Antes lo usaba ocasionalmente para una clase del instituto y también en unas prácticas durante el verano.
¿Cuánto tiempo llevas haciendo cambios en el núcleo de Python?
Desde hace más o menos un año. El 24 de marzo hará una año de pertenencia al grupo.
¿Cómo comenzaste como desarrollador del núcleo? ¿Recuerdas tu primer cambio?
Comencé cuando me di cuenta en el trabajo de un problema en la documentación mientras estaba escribiendo un módulo de extensión, envié un pequeño parche y Georg Brandl lo publicó casi instantáneamente. Después de este rápido éxito y obtener unos fuentes frescos, me puse a investigar y a aprender más sobre los módulos que usaba normalmente y terminé escribiendo un parche para añadir soporte de gestión del contexto al módulo zipfile.
Las primeras modificaciones enviadas fueron correcciones de la documentación para mantenerlo todo de forma más simple. Mi primer envío de código consistió en añadir algunas características y expandir la cobertura de los casos de prueba en el módulo winreg.
¿En qué partes de Python estás trabajando ahora?
Siendo uno de los pocos usuarios Windows involucrados en el desarrollo de CPython, intento echar un vistazo a cualquiera de los problemas que tienen los usuarios de Windows. Debido a esto, he tenido la oportunidad de trabajar bastante en la biblioteca estándar, incluyendo módulos que ni siquiera he usado. No he trabajado mucho en el intérprete mismo, pero pienso cambiar eso.
¿Qué haces con Python cuando no estás trabando en el desarrollo del núcleo?
Construyo un serie de herramientas para casos de prueba para una base de datos de comercio escrita en C++. Hay disponible un módulo de extensión para la API de datos de forma que podemos escribir fácilmente casos de prueba de regresión y rendimiento; siempre tratamos de construir más.
¿Qué haces cuando no estás programando?
Soy un gran seguidor del béisbol. Soy árbitro de béisbol en un instituto en primavera, algunas ligas en verano, y trato de ir a ver cómo juegan los Chicago Cubs.

Conoce al equipo: Nick Coghlan

Artículo original: Meet the Team: Nick Coghlan
Esta entrada es una más de la serie "Conoce al equipo", la cual está pensada como una pequeña introducción al equipo de desarrollo del núcleo de Python.

Nombre:	Nick Coghlan
Lugar:	Brisbane, Australia
Página Web:	http://www.boredomandlaziness.org

¿Cuánto tiempo llevas usando Python?
El primer encuentro fue con la versión 1.5.2 aproximadamente en 1999 cuando vi que nuestro ponente lo usaba en un curso de redes. Comencé a usar la versión 2.2 en el entorno profesional para generar casos de prueba de forma automática allá por el 2002 y nunca lo he lamentado.
¿Cuánto tiempo llevas haciendo cambios en el núcleo de Python?
Guido me dio acceso en 2005 para actualizar la PEP 343 (principalmente para poner en marcha el método de contexto)
¿Cómo comenzaste como desarrollador del núcleo? ¿Recuerdas tu primer cambio?
En lo que al envío de parches se refiere, dispuse de tres meses libres en 2004 en los cuales trabajé mucho con Raymond y Facundo en el módulo decimal, principalmente ejecutando pruebas de rendimiento de telco y buscando formas de acelerar la ejecución del código. Algunos de los arreglos más extraños que hay en el módulo decimal (por ejemplo, la ruta rápida para comprobar los casos especiales y el uso de cadenas de caracteres cuando se convierten tuplas de dígitos a enteros) se realizaron por aquellas fechas.
Realmente, la primera de mis modificaciones podría haber sido una realizada para la PEP 343, y después de esto alguna al compilador AST que incluimos en la versión 2.5.
¿En qué partes de Python estás trabajando ahora?
Las principales cuestiones que tengo sobre mi mesa están relacionadas con runpy, functools y contextlib. Tampoco pierdo de vista lo que están haciendo Brett y Victor en el módulo import, lo que hace Raymond con los módulos collections e itertools y cualquier cosa que suceda en el compilador. Me encanta también la faceta cultural de estas cosas.
¿Qué haces con Python cuando no estás trabajando en el desarrollo del núcleo?
Nada importante realmente. Los asuntos de Python en el trabajo simplemente funcionan correctamente, por lo que no hay muchas oportunidades de hacer "arreglillos" en este momento. Quiero hacer algo para ordenar mi biblioteca de música digital, pero los guiones que uso para esto son simplemente un apaño por el momento.
¿Qué haces cuando no estás programando?
Taekwondo, videojuegos, fútbol, lectura, etc, etc...

Nuevo diseño del Blog

Si usas un lector de noticias para estar al día de Python Insider, puede que no hayas notado el nuevo diseño de pagina que Marcin Wojtczuk ha creado. Tiene un aspecto fantástico a la vez que una sensación de ligereza. No podríamos estar más felices con los resultados.
¡Muchas gracias por tu tiempo y esfuerzos Marcin!

Corregida vulnerabilidad en la seguridad de urllib/urllib2

Artículo original: urllib Security Vulnerability Fixed
Guido van Rossum publicó recientemente una corrección para la incidencia CVE-2011-1521, una cuestión de seguridad en las bibliotecas URL de Python. Aunque las cuestiones relacionadas con la seguridad no son muy comunes, es una buena ocasión para dar a la comunidad la oportunidad de conocer el proceso detrás del informa, la gestión y la corrección de estos problemas cuando surgen.

Informar de un fallo

Si has encontrado un fallo en la seguridad dentro de CPython, lo primero que debes hacer es obtener los detalles del fallo de forma privada. Después de determinar que has encontrado un fallo de seguridad legítimo, generar un informe sucinto pero detallado es clave para transferir tus averiguaciones a los desarrolladores principales.
Un buen informe explica claramente cómo las partes relevantes del sistema están afectada por el fallo. También es positivo saber si el fallo ocurre en una plataforma específica o es debido a una dependencia. Es útil igualmente conocer las versiones afectadas y es probable que la vulnerabilidad sea comprobada también para todas las versiones activas. Finalmente, si has comprobado un caso de prueba que demuestre que el fallo se produce, asegúrate de incluirlo. Debes enviar tu informe al grupo security@python.org.
Recientemente Niels Heinen del Equipo de Seguridad de Google, presentó un buen informe. Descubrió un fallo en el manejo de redirecciones HTTP 302 en los módulos de las bibliotecas estándar urllib y urllib2. Lo que encontró fue que un servidor podía redirigir peticiones a esquemas inapropiados, llevando a situaciones en las cuales los datos o los sistemas podían ser comprometidos. En su informe inicial, Neils explica dos escenarios en los que estas redirecciones podrían causar problemas.
En primer lugar, ya que urllib/urllib2 ofrecen un manejador para el esquema URL file://, una redirección a file:///etc/passwd podría exponer información de contraseñas. Neils también explicó que la redirección a un dispositivo del sistema como file:///dev/zero podría generar un agotamiento de los recursos, desembocando en una denegación de servicio.

Gestionar un informe

Debido a la naturaleza sensible de los informes de seguridad, la lista security@python.org es mantenida por un pequeño grupo de desarrolladores de confianza, los cuales analizan y actúan sobre los informes tan pronto como les es posible. Si quieres comunicarte con la lista usando cifrado, lee la página noticias sobre seguridad para detalles sobre OpenPGP.
Si el grupo determina que se ha detectado un fallo en la seguridad, se anunciará un informe público de error con el correspondiente parche. En el caso que nos ocupa, Guido van Rossum anunció públicamente el fallo en la issue #11662, completándolo con un parche inicial.

Corregir el fallo

Lo que no hace el parche de Guido es restringir la redirección a los esquemas URL http://, https:// y ftp://. La redirección FTP fue juzgada como aceptable y es una redirección muy común actualmente: Los sistemas de descargas espejo en ocasiones redireccionan peticiones a servidores FTP más convenientes geográficamente hablando.
Para Python 2.x, el método redirect_internal de FancyURLopener arroja ahora una excepción IOError cuando se solicita la realización de una redirección a un esquema inapropiado. El método http_error_302 de HTTPRedirectHandler hace lo mismo, arrojando HTTPError únicamente. En Python 3, las mismas correcciones se realizaron en urllib.request. Se incluyeron con el parche dos pruebas las cuales ponen en práctica la redirección en esquemas válidos e inválidos.
En lo que a los usuarios se refiere, el lanzamiento final de seguridad de Python 2.5 se realizará pronto. Aunque todavía no hay fechas establecidas para los siguientes parches en las ramas de mantenimiento (2.6, 2.7, 3.1, y 3.2) se les ha aplicado el parche para resolver esta vulnerabilidad.

Conoce al equipo: Tarek Ziadé

Artículo original: Meet the Team: Tarek Ziadé
Esta entrada es una más de la serie "Conoce al equipo", la cual está pensada como una pequeña introducción al equipo de desarrollo del núcleo de Python.

Nombre:	Tarek Ziadé
Lugar:	Turcey cerca de Dijon, Borgoña (Francia)
Página Web:	http://ziade.org

¿Cuánto tiempo llevas usando Python?
Alrededor de diez años.
¿Cuánto tiempo llevas haciendo cambios en el núcleo de Python?
Desde el 21 de diciembre de 2008.
¿Cómo comenzaste como desarrollador del núcleo? ¿Recuerdas tu primer cambio?
Comencé a trabajar como desarrollador del núcleo para mantener Distutils y hacerlo evolucionar.
Mi primer cambio como desarrollador del núcleo fue una corrección a un pequeño fallo en una característica de distutils que propuse antes de tener los privilegios para hacer cambios. Esta característica se añadió la semana anterior a Python. Ofrece la posibilidad de configurar el registro de Distutils y de enviar los comandos para que se pueda trabajar con distintos servidores compatibles con pypi.
Hice mis primeros cambios con mis recién estrenados privilegios el 24 de diciembre de 2008, que, casualmente coincidía con mi cumpleaños y con el decimoséptimo aniversario de la versión 0.9.4 de Python.
¿En qué partes de Python estás trabajando ahora?
En las bibliotecas estándar: sysconfig, distutils, packaging (que será añadida en la versión 3.3), shutil, pkgutil, y ocasionalmente en otros módulos.
¿Qué haces con Python cuando no estás trabajando en el desarrollo del núcleo?
Trabajo en el equipo de servicio de Mozilla, en el cual construyo servicios web usando Python
¿Qué haces cuando no estás programando?
Leo cómics y novelas gráficas, escribo libros, juego con mis hijos, bebo vino con mi mujer e intento reformar mis casa de 1848.

Formalizando las Directrices de Control de Cambios de AST

Artículo original: Formalizing the AST Change Control Policy
Python ofrece un árbol de sintaxis abstracta (AST) que representa la forma compilada del código fuente Python en el módulo AST. El módulo AST permite que el código de usuario inspeccione y manipule la representación AST; se halla por tanto entre el análisis sintáctico del código y la compilación a código byte (bytecode).
Mientras que el código Python se define en la referencia del lenguaje, el módulo AST es un detalle de la implementación CPython y no es necesaria en otras implementaciones de Python.

Compatibilidad del AST

Como parte del trabajo de reescritura del optimizador local de CPython para trabajar en el AST (en lugar del código byte en bruto, como se realiza actualmente), Eugene Toder necesitaba hacer algunos cambios a la estructura del AST. Un detalle en la implementación de CPython era que no estaba del todo claro qué directrices de compatibilidad hacia atrás se podían aplicar al AST. De modo que Eugene preguntó en python-dev: ¿Es necesario, cuando cambie el AST, asegurar la compatibilidad hacia atrás?
El consenso general resultó en que no era necesaria esta compatibilidad. El módulo AST dispone de una constante ast.__version__, que ofrece al código de usuario una forma de variar el comportamiento dependiendo de la versión del AST con que se encuentre. Esto resultó ser suficientemente compatible para un módulo de implementación específica.

Otras implementaciones Python

Actualmente, los mantenedores de Jython e IronPython han hecho notar que sus respectivas implementaciones, tenían un módulo de compatibilidad AST, o bien se ofrecerá uno en el futuro. A pesar de esto, no opinan que esto signifique que el AST deba ser congelado y no les importa saber que cuando la constante ast.__version__ cambie, el AST deberá ser modificado para que sea compatible.
Un aspecto que salió a la luz, es que el conjunto de casos de prueba en test_ast.py ayudaría a otras implementaciones a asegurar que sus representaciones AST son compatibles con CPython. ¡Un buen proyecto para alguien que quiera involucrarse en los aspectos internos de Python, sería incrementar la cobertura de test_ast.py!

¿Qué ocurrirá a continuación?

El parche que motivó la discusión todavía no ha sido incluido en CPython. Por lo que, probablemente, nada vaya a cambiar. Sin embargo, si no se incorpora, el AST cambiará de forma que sea incompatible. La constante ast.__version__ se modificará para reflejar esto, de modo que el código de usuario detectará el cambio, pero deberá ser igualmente modificado. De forma más general, este será el modo en que se gestionen los cambios al AST en el futuro.
Los desarrolladores de Python están interesados en la medida en que se está usando el AST y en el impacto que estas directrices tendrán. Si algún lector tiene código afectado por este cambio, es recomendable que participen en la discusión que se mantiene en python-dev.

Thomas Heller renuncia como mantenedor de ctypes

Artículo original: Thomas Heller Steps Down as ctypes Maintainer
La comunidad de desarrollo de Python le debe un gran agradecimiento al mantenedor durante mucho tiempo de ctypes, Thomas Heller. A principios de este mes, Thomas anunció su marcha del proyecto CPython, el hogar de su biblioteca ctypes desde Python 2.5.
Tuve la oportunidad de hablar con Thomas y él me contó su historia con Python y sus proyectos ctypes y py2exe.

Python

En 1999 Thomas se topó con el libro Programming Python de Mark Lutz mientras estaba buscando recursos para aprender Python y quedó fascinado de inmediato con el lenguaje. Estaba inmerso en el proceso de reemplazar Scheme como lenguaje de extensión de un gran programa en C que había escrito para Windows.
En cuanto a la forma en que se introdujo en el equipo de desarrollo, su primera contribución a CPython (y open source en general), fue un pequeño parche relacionado con Windows para distutils. Su interés en distutils le llevo en última instancia a la creación del comando bdist_wininst para crear instaladores para Windows de tipo "apunta y haz clic". Desde entonces Greg Ward le invitó al grupo python-dev donde con el tiempo se le concedió acceso para modificación.

py2exe

Como muchos usuarios de Windows, tuvo la necesidad de desplegar aplicaciones Python como un solo archivo ejecutable. Los primeros enfoques al problema vinieron de las lumbreras de Python squeeze de Fredrik Lundh y sqfreeze de Christian Tismer, y Thomas contribuyó varios parches al proyecto Installer de McMillan.
Su interés en distutils llevó a Thomas a considerar portar Installer a una extensión de la biblioteca de empaquetamiento. Sin embargo, terminó reescribiendo las fuentes para hacer uso del marco de trabajo distutils ya existente. Al final, eligió el simple y a la par descriptivo nombre de py2exe para el proyecto.

ctypes

La idea para ctypes vino de la necesidad de llegar más allá de lo que aportaba pywin32 en ese momento. Además, su trabajo con Scheme requería de un interfaz con las APIs de Windows muy parecido a su labor hecha con Python, por lo que quería mantener su proyecto en marcha.
ctypes salió a la luz por primera vez en 2003 a la par de la versión 2.3 de Python, después Thomas recibió numerosas peticiones para publicar el proyecto. Lo que solía llamar su pequeño proyecto personal en su página Starship se convirtió en una biblioteca ampliamente usada en poco tiempo.
Originalmente empezó el proyecto en Windows pero pronto escuchó las llamadas para portarlo a Linux, para lo cual le ayudo la comunidad. Con la versión para Linux vino la introducción de libffi al proyecto, la cual empezó a usar en Windows para reemplazar su implementación de bajo nivel.
En 2006 se liberó la versión 1.0 para ctypes, lo que correspondió con su aceptación en la biblioteca estándar de Python 2.5. Después de años de duro trabajo y numerosas versiones cada año, ctypes fue entonces empaquetada con Python para estar disponible a una audiencia mucho más amplia.
Mucha gente ayudó a que ctypes sea lo que es hoy en día, y Thomas desea dar las gracias a todos los que participaron, especialmente a Robin Becker. La participación de Robin fue decisiva en las primeras fases del proyecto en las cuales contribuyó con conocimiento y ánimo.

Un nuevo mantenedor de ctypes

Después del duro trabajo que Thomas hizo a lo largo de los años, no nos gustaría ver como el proyecto se queda estancado. Si tienes experiencia en C y tiempo para ayudar al proyecto Python, la comunidad agradecería enormemente tu esfuerzo. Echa un vistazo a la nueva developer guide y busca en el bug tracker para más información.
Actualización: Corregidos algunos enlaces.