Conoce al equipo: Michael Foord

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

Nombre:	Michael Foord
Lugar:	Northampton (Reino Unido)
Página Web:	http://www.voidspace.org.uk/

¿Cuánto tiempo llevas usando Python?
En 2002 comencé a usar Python como un hobby. En mi trabajo fue donde empecé a usar Python a tiempo completo en 2006. Cuando empecé a programar en Python, formaba parte de un grupo de gente que querían escribir un programa para acumular información procedente de un juego por correo. Ninguno de nosotros había programado desde hacía algún tiempo, y estábamos decididos a utilizar Smalltalk cuando alguien sugirió que lo intentáramos en Python. Rápidamente me enamoré de Python.
¿Cuánto tiempo llevas haciendo cambios en el núcleo de Python?
Conseguí hacerme mantenedor del núcleo durante el PyCon del 2009. Esto se debió originalmente a mi participación en IronPython.
¿Cómo comenzaste como desarrollador del núcleo? ¿Recuerdas tu primer cambio?
Durante los sprints de PyCon 2009, trabajé con Gregory Smith, otro desarrollador del núcleo, para incorporar algunas mejoras a unittest contribución de Google.
¿En qué partes de Python estás trabajando ahora?
Después de este trabajo inicial con unittest en el sprint del PyCon, me encargué de corregir otras cuestiones y realizar cambios a unittest, que entonces no tenía mantenedor. Me convertí en el mantenedor de unittest y también contribuí en otras partes de la biblioteca estándar.
Estoy involucrado en apoyar a Python en otros maneras menores, como estar pendiente del Planet Python, ser miembro de la PSF, ayudar como alias del webmaster de python.org y cosas por el estilo.
¿Qué haces con Python cuando no estás trabajando en el desarrollo del núcleo?
En mi trabajo diario, realizo desarrollo web para Canonical. Trabajo en algunos servicios de infraestructura web en los sitios web de Canonical y también en algunos de los servicios que se integran con Ubuntu. Pasamos muy buenos ratos, es un equipo muy bueno.
En mi tiempo libre, trabajo en proyectos como unittest2 (un backport de las mejoras hechas a unittest para otras plataformas), mock (una biblioteca de pruebas que ofrece objetos mock y soporte para realizar monkey patching en los casos de prueba) y unas cuantas cosas más sin mucha importancia.
Me gustaría escribir más, pero como he entregado la mejor parte de dos de mis años a escribir "IronPython in Action", dudo que comience en breve ningún proyecto que conlleve mucha escritura.
¿Qué haces cuando no estás programando?
Estoy muy involucrado en una iglesia en Northampton (Reino Unido), lo que me lleva mucho de mi tiempo. Ayudo con la administración de acciones de caridad que realizamos. Esta es una de las razones por las que es bueno trabajar para Canonical: puedo trabajar desde casa, plantar aquí mis raíces y no irme a ningún otro lugar (aunque ciertamente no es el clima lo que me ata aquí). Y no es necesario decir que que no se realiza mucho desarrollo Python en Northampton. Mi primer trabajo como programador a tiempo completo fue en Londres formando parte de un equipo increíble, que implicaba dos horas de viaje para llegar desde mi casa al trabajo cada día (dos de ida y dos de vuelta). Aguanté cuatro años así, y realmente disfruté del trabajo, pero habiéndome salvado de esos traslados no creo que vaya a volver.
También me gusta jugar con la XBox. Desgraciadamente si encuentro un juego que me gusta, me puedo viciar con él durante semanas, por lo que tengo que tener cuidado. Evito jugar a world of warcraft y eve online por esta razón... También organizo reuniones mensuales de geeks en Northampton. En este grupo no hay suficientes programadores de Python para hacer un grupo de usuarios de Python pero tenemos gente con gustos variopintos. Normalmente nos juntamos en un bar y le damos a la lengua o nos enseñamos nuestros últimos gadgets.

Un lanzador python para Windows

Artículo original: A Python Launcher For Windows

Mark Hammond (autor de pywin32 y mantenedor de Python para Windows desde hace tiempo) ha escrito PEP 397, que describe un nuevo lanzador de Python para Windows. Vinay Sanjip (autor del módulo logging de la biblioteca estándar) ha creado recientemente una implementación del lanzador. Se puede descargar desde https://bitbucket.org/vinay.sajip/pylauncher/downloads

El lanzador permite que los guiones Python (ficheros .py y .pyw) en Windows especifiquen la versión de Python que debe ser usada, permitiendo el uso simultáneo de Python 2 y 3.

Los usuarios de Windows deberían considerar descargar el lanzador y probarlo para ayudar a los desarrolladores de Python a rematar cualquier cuestión pendiente. El lanzador está empaquetado como aplicación independiente y soportará las versiones de Python disponibles actualmente. La intención, una vez haya finalizado el desarrollo del lanzador, es incluirlo como parte de Python 3.3 (aunque seguirá disponible como aplicación independiente para usuarios de versiones anteriores).

Hay disponibles dos versiones del lanzador - launcher.msi que se instala en el directorio Archivos de programa, y launchsys.msi que se instala en el directorio System32 de Windows. (Hay versiones de 64 bits para versiones de Windows de 64 bits).

Algunos detalles acerca del lanzador

La especificación completa del comportamiento del lanzador se encuentra el PEP 397. Un resumen de los principios básicos:

• El lanzador incluye dos ejecutables - py.exe (la versión consola) y pyw.exe (la versión GUI).
• El lanzador se registra como gestor para las extensiones de fichero .py (consola) y .pyw (GUI).
• Cuando se ejecuta un guión, el lanzador buscará una línea #! (shebang) al estilo Unix en el guión. El lanzador reconoce los siguientes nombres de ejecutables: python (python del sistema por defecto), python2 (versión por defecto de Python 2) y python3 (versión por defecto de Python 3). Los detalles exactos se pueden personalizar fácilmente por usuario o por máquina.
• Cuando se usa de forma independiente, el comando py.exe lanza el intérprete interactivo de Python. Se pueden especificar opciones en la línea de comandos, de forma que py -2 lanza Python 2, py -3 lanza Python 3, y py la la versión por defecto.

Instrucciones de uso sencillas

Cuando se ha instalado, el lanzador se asocia a si mismo con los guiones .py y .pyw. Si no haces nada más, los guiones serán ejecutados usando el intérprete de Python por defecto de la maquina, por lo que no verás ningún cambio. Algo que quizás quieras hacer, si usas mucho la consola, es añadir .py a tu variable PATHEXT para que los guiones no se ejecuten en una consola independiente.

Para especificar que un guión tiene que usar Python 2, simplemente haz que:

#!/usr/bin/env python2

sea la primera línea del guión. (Esto es un formato compatible con Unix. Si no necesitas compatibilidad con Unix, utiliza #!python2).

Por otro lado, si quieres especificar que un guión tiene que usar Python 3, haz que:

#!/usr/bin/env python3

sea la primera línea.

También puedes iniciar el intérprete Python usando cualquiera de los siguientes comandos:

# Versión por defecto de Python
py
# Python 2
py -2
# Python 3
py -3

Para que esto funcione el ejecutable py.exe tiene que estar en tu ruta. Esto se configura de forma automática con la versión launchsys del instalador, pero con launcher.msi el directorio de instalación (C:\Archivos de programa\Python Launcher) debe ser añadido manualmente a PATH.

Más información

Los siguientes hilos de correos en python-dev cubren algunas de las discusiones clave:

• Anuncio inicial de Mark del borrador PEP: http://mail.python.org/pipermail/python-dev/2011-March/109509.html
• El segundo borrador del PEP: http://mail.python.org/pipermail/python-dev/2011-March/109786.html
• Cuestión inicial de Vinay sobre una implementación en C del lanzador: http://mail.python.org/pipermail/python-dev/2011-June/112145.html
• Anuncio de Vinay de su implementación en C: http://mail.python.org/pipermail/python-dev/2011-July/112184.html
• Llamamiento de Vinay para probadores: http://mail.python.org/pipermail/python-dev/2011-July/112251.html

Lanzado CPython 3.2.1

Artículo original: CPython 3.2.1 Released

En nombre del equipo python-dev, el responsable de lanzamientos Georg Brandl ha anunciado el lanzamiento final de CPython 3.2.1. Los instaladores para Windows y los archivos tar están disponibles desde el 10 de julio, por lo que, por favor, considera actualizar a esta versión.

El documento What's New lista las nuevas características de la versión 3.2, y el fichero Misc/NEWS en el código fuente lista todos los bugs corregidos.

Si encuentras cualquier problema con esta versión o cualquier otra, por favor repórtalo en http://bugs.python.org/.

Liberada la versión candidata 3.2.1

Artículo original: 3.2.1 Release Candidate 2 Released

Después de un gran mes de junio en el que se han producido varios lanzamientos, la segunda versión candidata de la línea 3.2.1 ya está preparada. Desde el lanzamiento de la primera versión candidata el 15 de mayo, se han corregido cerca de 40 cuestiones que estaban pendientes. Animamos a todo el mundo a que prueben sus proyectos con esta versión para tener una última visión antes del lanzamiento final de la versión 3.2.1.

¿Qué se ha corregido?

E/S

El bug #1195 llevaba varios años sin ser resuelto, sin embargo, una pequeña adición para la limpieza de errores antes de llamar a fgets solucionó el problema de interrumpir a sys.stdin.read() con CTRL-D dentro de input(). Se ha realizado una limpieza del sistema io en el bug #12175 en el que el método readall retornando None cuando al llamar a read() esta última retornaba None, y ahora se lanza una excepción ValueError cuando no se puede abrir un fichero.
Aunque esto no es nuevo en la RC2, el bug #11272 es una corrección importante a la función input() para la versión 3.2.1 de Windows al corregir un \r que se encuentra al final. Esta cuestión afectaba a muchos usuarios y se ha informado de ella en numerosas ocasiones (¿a alguien le suena el comando upload de distutils?), así que esperamos que la versión 3.2.1 lo solucione.

Windows

La versión 3.2.0 introdujo una nueva característica para Windows: el soporte para os.symlink. Esto trajo consigo el bug #12084, os.stat estaba evaluando incorrectamente los enlaces simbólicos en Windows, por lo que se realizaron correcciones en el funcionamiento interno de las diversas funciones stat.
Un usuario informó de la lentitud de os.path.isdir. El hecho de que necesitara de os.stat contribuía a esto, especialmente cuando se evaluaban enlaces simbólicos (los cuales son dos veces más lentos que los ficheros regulares). Aunque os.path.isdir no es precisamente un cuello de botella para nadie, lo cierto es que se llama en numerosas ocasiones en el arranque del intérprete, de modo que al cambiarlo en la bug #11583 para que utilice GetFileAttributes se obtiene una pequeña mejoría con la que se puede trabajar.

subprocess

Crear un objeto Popen con argumentos inesperados estaba causando una excepción AttributeError, lo cual fue notificado en el bug #12085 y corregido por la misma persona que informó de este hecho. Debido a un cambio en la versión 3.2.0, Popen no estaba manejando correctamente variables de entorno vacías, específicamente el argumento env. Se creó el bug #12383 para esta cuestión, el cual fue corregido rápidamente.

...¡y aún más!

Para un listado completo de los cambios en la versión 3.2.1 RC2, ¡comprueba el registro de cambios y descárgatelo ahora!
Como de costumbre, por favor, informa en http://bugs.python.org de cualquier incidencia que encuentres. Apreciaremos tu ayuda en la creación de versiones robustas de Python.

Lanzamientos de junio - 2.6.7, 2.7.2, 3.1.4

Artículo original: June Releases - 2.6.7, 2.7.2, 3.1.4

Junio es un gran mes para lanzamientos de Python, con una actualización en cada una de las ramas activas.

2.6.7

Está disponible un nuevo lanzamiento de código fuente de Python 2.6.7 que aporta correcciones a tres cuestiones de seguridad. Ahora que la línea 2.6 está en modo seguridad, estos lanzamientos se producirán en forma de código fuente cada vez que se necesiten hasta octubre de 2013. Si necesitas instaladores binarios, deberías considerar actualizar a 2.7 o 3.2.

La versión 2.6.7 es el primer lanzamiento en el que se corrige la vulnerabilidad urllib ya comentada. Además se han arreglado una vulnerabilidad DoS en smtpd (cuestión #9129) y una vulnerabilidad XSS en SimpleHTTPServer.list_directory (cuestión #11442).

2.7.2

Se realizaron más de 150 correcciones a la última versión menor de la línea 2.x, la 2.7, desde su versión 2.7.1 de noviembre de 2010. Desde el 12 de junio está disponible el código fuente y el instalador binario para la 2.7.2, la cual incluye las correcciones de seguridad mencionadas en la 2.6.7.

Varios fallos han sido corregidos: una situación en la que Python usaba incorrectamente memoria no gestionada por él mismo mientras la modificaba otro hilo, cuando se eliminaba __abstractmethods__ de una clase, accediendo un fichero mapeado en memoria más allá de su longitud, y varios otros.

Una corrección en getpass soluciona una regresión en relación a la gestión de CTRL-C y CTRL-Z. multiprocessing recibió varias correcciones, incluyendo el tratamiento de servicios de Windows como p. ej. el de ejecutables congelados y una corrección de condición de carrera cuando terminan los (procesos) trabajadores de multiprocessing.Pool. mmap fue corregido para trabajar con tamaños de fichero y desplazamientos superiores a 4 GB incluso en compilaciones de 32 bit, y ahora se produce un TypeError en lugar de producir un fallo de segmento cuando se intenta escribir a un mapa no escribible.

Para una lista completa de cambios, véase el fichero de novedades 2.7.2.

3.1.4

La versión 3.1.4 es el último lanzamiento que corrige bugs de la línea 3.1.x, enviando la 3.1 al modo de seguridad mientras la línea 3.2 continua. La versión 3.1.4 contiene más de 100 correcciones de bugs desde el lanzamiento de la 3.1.3 en noviembre de 2010. Al igual que con la 2.7.2, están disponibles instaladores binarios desde el 12 de junio, y además la 3.1.4 es el primer lanzamiento 3.x en contener los arreglos de seguridad listados en 2.6.7.

La versión 3.1.4 corrige varios problemas con búsquedas __dir__ sobre objetos, fechas posteriores al 2038 en la implementación para Windows de os.stat y os.utime, y una serie de limpiezas para 64 bits. Se realizaron una serie de cambios en la biblioteca io para retornar None cuando no se había leído nada y lanzando las excepciones apropiadas en otros puntos. Se corrigieron los argumentos de llamada de ctypes para Windows 64 bits y también se corrigió un fallo en la ejecución.

Para una lista completa de cambios, véase el fichero de novedades 3.1.4.

3.2.1

La versión 3.2.1 está actualmente en la fase de candidata a lanzamiento, con una ronda ya completada y se espera un segunda versión candidata en breve. Queremos agradecer enormemente a los usuarios de la versión 3.2 las pruebas de la versión candidata a lanzamiento para asegurar que cubrimos cualquier cuestión que puedas encontrar. Si tienes que reportar cualquier bug, por favor regístralo en bugs.python.org.

Traducciones al portugúes, alemán, coreano y chino tradicional

Artículo original: Python Insider Translation Project

¡El proyecto de traducción de Python Insider continúa creciendo! Hoy lanzamos la versión portuguesa, alemana, coreana, y china tradicional del blog. Los traductores ya han empezado a traducir las entradas anteriores. Tal como ocurre con las otras traducciones, estas ediciones paralelas estarán un poco retrasadas con respecto a las entradas originales en Python Insider.

El nuevo módulo para la gestión de fallos en Python 3.3 ayuda en la depuración

Artículo original: New faulthandler module in Python 3.3 helps debugging

Cuando un usuario reporta que tu programa ha fallado o se cuelga, algunas veces sólo puedes ayudar a probar y recoger más información y componer un escenario para reproducir la situación. Incluso con un escenario fidedigno de usuario, como desarrollador muchas veces eres incapaz de reproducir la situación debido a diferencias en el entorno, p. ej., sistema operativo y compilador. Si tienes suerte, el usuario podrá instalar herramientas de depuración, pero la mayoría de las veces tendrás que esperar a que otra persona pueda obtener más información sobre la situación.

Errores fatales

En Python 3.3 se ha introducido un nuevo módulo que te ayudará a resolver este problema: faulthandler. faulthandler proporciona la habilidad de volcar la traza inversa de Python en un error fatal tal como sucede en un fallo de segmento, división por cero, abortado o error de bus. Puedes habilitarlo dentro de tu aplicación usando faulthandler.enable(), incorporando la opción -X faulthandler al ejecutable Python, o con la variable de entorno PYTHONFAULTHANDLER=1. Ejemplo de salida:

Fatal Python error: Segmentation fault

Current thread 0x00007f7babc6b700:
  File "Lib/test/crashers/gc_inspection.py", line 29 in g
  File "Lib/test/crashers/gc_inspection.py", line 32 in <module>
Segmentation fault

Tiempo de espera

faulthandler también puede volcar la traza inversa después de un tiempo de espera usando faulthandler.dump_tracebacks_later(timeout). Llámalo otra vez para reiniciar el temporizador o llama a faulthandler.cancel_dump_tracebacks_later() para parar el temporizador. Ejemplo de salida:

Timeout (0:01:00)!
Current thread 0x00007f987d459700:
  File "Lib/test/crashers/infinite_loop_re.py", line 20 in <module>

Usa la opción repeat=True para volcar la traza inversa cada timeout segundos, o exit=True para salir del programa inmediatamente de forma insegura, p. ej. no volcando el buffer de archivos a disco.

Señal de usuario

Si tienes acceso a la maquina en la cual se está ejecutando el programa, puedes usar faulthandler.register(signal) para instalar un gestor de señal que vuelque la traza inversa cuando se reciba signal. En UNIX, por ejemplo, puedes usar la señal SIGUSR1: kill -USR1 <pid> volcará la traza inversa actual. Esta funcionalidad no está disponible bajo Windows. Ejemplo de salida:

Current thread 0x00007fdc3da74700:
  File "Lib/test/crashers/infinite_loop_re.py", line 19 in <module>

Otra posibilidad es llamar explícitamente a faulthandler.dump_traceback() en tu programa.

Temas de seguridad y el fichero de salida

faulthandler está deshabilitado por defecto por razones de seguridad, principalmente porque almacena el descriptor de fichero de sys.stderr y escribe las trazas inversas en este descriptor de fichero. Si se cierra sys.stderr y se reusa el descriptor de fichero, este descriptor puede ser un socket, una tubería, un fichero crítico o cualquier otra cosa. Por defecto, faulthandler escribe las trazas inversas en sys.stderr, pero puedes especificar otro fichero. Para más información, consulta la documentación de faulthandler.

Módulo de terceros para versiones antiguas de Python

faulthandler también es mantenido como un módulo de terceros para Python 2.5 hasta 3.2 mediante PyPi. La mayor diferencia entre el módulo Python 3.3 y el módulo de terceros es la implementación de dump_tracebacks_later(): Python 3.3 usa un hilo con un tiempo de espera en un bloqueo, por otro lado el de terceros usa SIGALRM y alarm().

El tiempo de espera del bloqueo (que es una nueva funcionalidad de Python 3.3), tiene una resolución de un microsegundo. El temporizador alarm() usado en versiones anteriores tiene una resolución de un segundo, y la señal SIGALRM puede interrumpir la llamada actual al sistema que fallará con un error EINTR.

Éxito rápido

El nuevo módulo faulthandler ya ha sido de ayuda en el rastreo de condiciones de carrera en nuestros buildbots. Esperamos que te ayude también en tus programas.

Traducciones a rumano y a chino simplificado

Artículo original: Romanian and Simplified Chinese Translations

El equipo de Python Insider se complace en anunciar hoy dos nuevos blogs. Al proyecto de traducción se han unido traductores de rumano y de chino simplificado, y han empezado a publicar los artículos pasados. Como el resto de traducciones, estas ediciones paralelas tendrán un ligero retraso con respecto a los artículos originales en Python Insider.

Migración de Jython a Mercurial

Artículo original: Jython Migrates to Mercurial
Por fin se ha migrado Jython de Subversion a Mercurial. Ha sido un proceso largo, debido a que desafortunadamente hemos tenido dificultades con el repositorio de Subversion. La limpieza de este repositorio ha necesitado bastante esfuerzo para ser convertido a un sistema de control de versiones diferente.
El nuevo repositorio oficial de Jython está ahora alojado en:
http://hg.python.org/jython
con un espejo BitBucket para hacer ramas de forma fácil.
Existe también un repositorio mayor de solo lectura con posibilidades de realizar ramas (convertidas a marcas de Mercurial). Este repositorio está alojado en http://hg.python.org/jython-fullhistory
Mercurial hace que las contribuciones a Jython sean más fáciles de realizar. ¡Créate una rama y ayúdanos a construir Jython 2.6!

Python 3.3 no ofrecerá soporte para OS/2, Windows 2000 y VMS

Artículo original: Python 3.3 to Drop Support for OS/2, Windows 2000, and VMS

De vez en cuando llega el momento en que se debe limpiar la lista de los
sistemas operativos soportados para ser realista en el uso de estos
sistemas. Además de esto, el número de desarrolladores especializados
en una plataforma es también importante, ya que se necesita que haya
siempre alguien con los conocimientos adecuados para ofrecer un producto
de calidad. Otros factores como la antiguedad del sistema operativo y el
estorbo que pueden suponer en futuros desarrollos también tienen su peso
en estas decisiones.

Victor Stinner propuso recientemente eliminar el soporte de OS/2 y VMS
para CPython un año después de la pregunta original sobre el
soporte de OS/2. La propuesta original de Victor llegó mientras trabaja
incansablemente en Unicode, especialmente en una cuestión relacionada
con el soporte de las variables de entorno en os.execvpe() a través del
manejador PEP 383 . Tanto OS/2 como VMS no tienen actualmente
representantes en el equipo de desarrollo y no se realizan pruebas durante
las fase de liberación de versiones.

El proceso de redacción de esta entrada me hizo pensar sobre una
discusión previa sobre eliminar Windows 2000, la cual parece haberse
caído del todo. Los sistemas que ajustaban COMSPEC a command.com
también fueron considerados para su eliminación. Actualmente, ambos
se han unido a OS/2 y VMS. Windows 2000 está preparado para ser eliminado
con el fin de facilitar el desarrollo, eliminando el hecho de estar
pendientes de las APIs oficiales en un sistema operativo que alcanzó el
final de su ciclo de vida en 2010.

Para eliminar el soporte de estos sistemas, Victor y yo comenzamos por
actualizar la PEP 11.

PEP 11

Esta PEP define los sistemas opertativos que ya no son soportados y explica el
proceso de adición de un nuevo sistema a la lista.

Una vez se decide que se puede comenzar el proceso de eliminación de un
sistema operativo, se anuncia oficialmente que ya no está soportado. Este
anuncio, tradicionalmente, va en la versión en desarrollo, de forma que
la eliminación del soporte de OS/2, Windows 2000 y VMS comienza con
Python 3.3.

El primer paso es sencillo, no hay nada más que levanter la bandera blanca.
Es una señal de que nadie mantiene el código ni asegura una versión de
calidad. Los cambios en compilación e instalación se realizan para
avisar a los usuarios de que esas plataformas ya no están soportadas. Una
nota se muestra en el listado del documento "What's New" listando las
nuevas plataformas sin soporte.

Después de un ciclo de liberación sin soporte, la versión obtiene el
visto bueno a una eliminación de código. En este caso, el código puede ser
eliminado en la versión 3.4. No se realizará (probablemente) una
eliminación completa, sin embargo los desarrolladores que trabajen en el
código pueden eliminar cualquier bloque #ifdef, secciones
configure o código desactualizado.

Qué Puedes Hacer

Si eres un usario de OS/2 o VMS, hay algunas cosas que puedes hacer para
evitar que tu plataforma deje de estar soportada.

Hazte Mantenedor

Nada dice más de un soporte que ser un desarrollador en activo. Andrew
MacIntyre ha sido el mantenedor de OS/2 durante algún tiempo, y anunció
durante la primera consulta sobre OS/2 de Victor que en este sistema
se quiere integrar el soporte Unicode, de modo que se trata de un área
en la que hay que centrarse. Parece que VMS tiene algún soporte externo
a través de http://www.vmspython.org, pero tal y como se ha discutido en
la issue 11918, alguien debe colaborar para que el soporte de VMS siga
realizándose por el equipo principal de desarrollo.

Si estás interesado en hacerte cargo de cualquiera de estas plataformas,
lee la guía del desarrollador para ver el estado de los procesos de
desarrollo actuales.

Contribuye con una versión esclava

Con un desarrollador activo, una plataforma tiene mayor probabilidad de
sobrevivir. Con una versión esclava, la plataforma tendrá aún más
posibilidades no sólo en lo que a supervivencia se refiere, sino también
en lo referente a la calidad.

Python usa Buildbot para la integración continuada, y se
ofrecen actualmente versiones esclavas para Linux, Mac, Windows y Open
Indiana (Solaris), para varias versiones, arquitecturas y configuraciones.
El hecho de donar una máquina para la flota de construcción de OS/2 o VMS
podría permitir que estas plataformas reciban la misma atención de las que
otras plataformas más mayoritarias reciben.

Si puedes donar tiempo o hardware para mantener vivos a OS/2 y VMS,
contacta con la lista de correo python-dev para coordinar tus
esfuerzos.

Proyecto de traducción de Python Insider

Artículo original: Python Insider Translation Project

Pensamos que el contenido de este blog es útil para toda la comunidad Python, por lo que alcanzar la mayor cantidad de público es una de nuestras prioridades. Para ampliar nuestro alcance estamos reuniendo un equipo de traductores para crear ediciones paralelas del blog en otros idiomas. Hoy lanzamos dos traducciones: japonés y español.

Las traducciones estarán un poco retrasadas con respecto a las publicaciones en Python Insider, pero estarán lo más actualizadas posible.

Necesitamos ayuda

El equipo de traducción es aún muy pequeño, por lo que estamos buscando gente para unirse a él. Necesitamos gente capaz de trabajar en los idiomas existentes, o que nos ayude a expandirnos a otros idiomas. Si puedes ayudar de alguna forma, contacta con Doug Hellmann (doug punto hellmann en gmail).

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.

Conoce al equipo: Benjamin Peterson

Artículo original: Meet the Team: Benjamin Peterson
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:	Benjamin Peterson
Lugar:	Minnesota (Estados Unidos)
Página Web:	http://benjamin-peterson.org/
Blog:	http://pybites.blogspot.com/

¿Cuánto tiempo llevas usando Python?
Tres años y medio.
¿Cuánto tiempo llevas haciendo cambios en el núcleo de Python?
Hará tres años exactamente el próximo 25 de marzo.
¿Cómo comenzaste como desarrollador del núcleo? ¿Recuerdas tu primer cambio?
Mi primer propuesta fue rechazada personalmente por Guido. Afortunadamente, insistí y conseguí que algunos de mis parches fueran aceptados. Creo que mi primer cambio fue el reordenamiento del fichero Misc/ACKS.
¿En qué partes de Python estás trabajando ahora?
Me gusta el parser, el compilador y el núcleo del intérprete, sin embargo soy conocido por tocar todas las partes en el desarrollo del núcleo de Python... ¡excepto lo referente a Windows!
¿Qué haces con Python cuando no estás trabajando en el desarrollo del núcleo?
¡Lo uso para implementar un intérprete de Python (http://pypy.org)!. Créeme, en el fondo soy un implementador de Python. :) Soy el creador de six (http://pypi.python.org/pypi/six), una biblioteca de compatibilidad de Python 2 y 3.
¿Qué haces cuando no estás programando?
Compongo música, toco el clarinete y leo libros de matemáticas. También salgo al campo de vez en cuando.

Características de Python 2.7 obsoletas en 3.x

Una reciente discusión en python-dev
puso de manifiesto un fallo en la actual política de obsolescencia (deprecation)
adoptada por los desarrolladores en la migración de 2.7 a la nueva 3.x.
En consecuencia, el equipo de desarrollo ha tenido que modificar su
política para tener en cuenta que los usuarios migrarán directamente de Python 2.7
a la última versión de 3.x, sin pasar por versiones intermedias.

Antecedentes

Python tiene un fuerte compromiso con la compatibilidad con versiones anteriores.
No se permite ningún cambio a menos que esté de acuerdo con las directrices de compatibilidad,
que en esencia dicen que programas correctos no deben fallar en versiones más modernas.
Sin embargo, esto no es siempre posible, por ejemplo, cuando una API deja de funcionar y debe ser
reemplazada por algo nuevo. En este caso, Python sigue una política de obsolescencia basada
en un periodo de transición de un año en el que las características a renovar son consideradas
formalmente obsoletas. En el periodo intermedio, se debe emitir un aviso (deprecation warning)
de forma que los programadores tengan tiempo de actualizar su código. Los detalles completos
de la política de Python están documentados en el PEP 5. Los cambios sólo se hacen
en las versiones nuevas y normalmente pasan 18 meses entre versiones; ergo la norma es
una versión en el periodo.

La única excepción ha sido Python 3. La nueva rama ha sido específicamente creada para permitir cambios que
rompieran la compatibilidad, permitiendo así a los desarrolladores de Python corregir problemas que,
simplemente, no podían solucionarse dentro de la política actual. Por ejemplo, hacer las cadenas
Unicode por defecto y devolver iteradores en lugar de listas.

Líneas paralelas de desarrollo

Sabiendo que la transción a Python 3 llevaría tiempo (unos 5 años, según varias estimaciones),
habría cierto desarrollo paralelo entre 2 y 3.

Con Python 2.7 como versión final de Python 2, se acordó que el periodo de mantenimiento
se extendería por un periodo substancial. Tarde o temprano, los desarrolladores que quieran
migrar a versiones más nuevas deberán dar el salto a Python 3.

He aquí uno de los problemas...

Obsolescencias sorpresa

En un hilo en python-dev`<http://mail.python.org/pipermail/python-dev/2011-March/109010.html>`__,
se señaló que una función específica de la API C, PyCObject_AsVoidPtr, había sido eliminada
con lo que parecían insuficientes avisos. Y, sin embargo, la política adoptada se supone que debería
proteger contra eso. ¿Qué pasó?

El cambio fue parte de una migración mayor desde una API más antigua, PyCObject, a una nueva y
mejorada, PyCapsule. El problema es que PyCObject es la predeterminada, y desde luego,
la única API disponible en Python 2.6. En 2.7 pasó a estar considerada obsoleta, y en Python 3.2
no existe, y la nueva PyCapsule debe ser usada. Esto supone un periodo de tránsito entre el
lanzamiento de 2.7 (julio del 2010) al lanzamiento de 3.2 (febrero del 2011) de siete meses; mucho
menor al mínimo de doce meses exigido, y hace más difícil dar soporte a un rango razonable de
versiones de Python.

Para alguien migrando de 3.0 a 3.1 y después a 3.2, el tránsito es correcto. Python 3.1 fue
lanzado en marzo del 2010 con la marca de obsolescencia, por tanto, en la serie 3.x hay un periodo
de casi 12 meses. Sin embargo, esto no es lo habitual: migran de 2.7 directamente a la última
versión de 3.x; en nuestro caso, 3.2, apareciendo este problema. Nunca fue la intención del equipo
de desarrollo, pero PEP 5 no se escribió para desarrollos de dos versiones en paralelo.

Entonces, ¿qué hacemos?

Dado que el problema con la API PyCObject/PyCapsule está bien definido, no es imposible
de evitar, pero al menos una persona de python-dev ha tenido algunos problemas con ello.
En resumen, esto no debería haber ocurrido.

Para el caso específico de PyCObject/PyCapsule, el problema ya existía y no había mucho
que se pudiera hacer. Reincorporar PyCObject no era una opción, dado que sólo añadiría nuevas
incompatibilidades. Sin embargo, la visión general fue que era posible, aunque tedioso, escribir
código que se adaptara a cualquier API disponible. De hecho, en Python 3.1, la API PyCObject
fue escrita como un wrapper de la PyCapsule. Había una sugerencia de que, en caso de ser necesitada,
el código de la implementación en 3.1 podría ser extraído y ser usado como código para terceros.
Adicionalmente, se acordó que se escribiría un PEP "retroactivo" cubriendo el cambio, para describir
las razones tras el cambio y documentar los recursos que ayudarían a los programadores a migrar.

El equipo de Python ahora está al tanto de los problemas y trabajará para evitar que vuelvan a ocurrir.
Guido publicó una reseña
de la situación y sugirió que Python 3 debería ser conservativo dejando características obsoletas
por el momento. Como mínimo, las API consideradas obsoletas se conservarán más tiempo antes de ser
eliminadas, para dar a los programadores migrando desde 2.7 un camino más fácil.

Más indirectamente, el hilo mostró el problema de cómo comunicar de forma más efectiva los cambios
en Python a una audiencia mayor, de forma más oportuna; una de las razones de ser de este blog.

¿Qué significa todo esto?

En primer lugar, significa que los desarrolladores de Python no lo hacen todo bien. Nadie
quiere hacer la vida de los programadores más difícil, simplemente no fue algo que se viera a tiempo.

En segundo lugar, arreglar el problema puede hacer aún más daño, así que PyCObject no se
reincorporará. Aunque eso ayudaría a los programadores afectados por el cambio, en global haría los problemas
de compatibilidad más complejos. Mientras tanto, tendremos que sobreponernos al problema y seguir adelante.
La lección está aprendida, y no volveremos a cometer el mismo error de nuevo.

Una hecho positivo puesto de manifiesto es que el equipo de Python escucha lo que sus usarios tienen que decirles.
La compatibilidad es muy importante, y se pone todo el esfuerzo en hacer la transición a nuevas versiones
tan indolora como sea posible. En particular, los desarrolladores de bibliotecas deberían ser
capaces de soportar varias versiones de Python con un nivel adecuado de esfuerzo.

Finalmente, los desarrolladores no han abandonado 2.7. No se implementarán nuevas características
y no existirá 2.8, pero la visión de los usuarios de 2.7 todavía es importante. Estar seguros de
que los usuarios pueden migrar a 3.x cuando estén listos es de vital importancia para la comunidad de Python.

Acerca de muestreos, módulo futures y ejecución en paralelo

Artículo original: Of polling, futures and parallel execution

Una de las mayores preocupaciones en la computación moderna es el ahorro de energía. Es muy importante en dispositivos portátiles (portátiles, tabletas, móviles). Una CPU moderna es capaz de entrar en un número variado de estados de ahorro de energía cuando está ociosa. Cuanto mayor tiempo se mantenga en estado ocioso, más profundo será el estado de ahorro de energía y menor será la energía consumida y por lo tanto, la duración de la batería será más larga en cada carga.

Los estados de ahorro de energía tienen un enemigo: los muestreos. Cuando una tarea activa la CPU periódicamente, incluso por algo tan trivial como leer una dirección de memoria para verificar si ha habido cambios potenciales, la CPU abandona el estado de ahorro de energía, activa a todas sus estructuras internas y solo volverá a entrar en este estado mucho después de haber terminado su labor causada por esa activación de poca importancia. Esto acaba con la vida de la batería. La propia Intel está preocupada por esto.

Python 3.2 viene con un nuevo módulo estándar para lanzar tareas concurrentes y esperar que terminen: el módulo concurrent.futures. Mientras hojeaba su código, noté que usaba muestreos en algunos de sus hilos y procesos trabajadores. Y digo «algunos de» ya que la implementación de ThreadPoolExecutor (basada en hilos) es diferente que la implementación de ProcessPoolExecutor (basada en procesos). El primero hace muestreos en cada uno de los hilos trabajadores, mientras que el último solo lo hace en un único hilo llamado el hilo de gestión de la cola, el cual se usa para comunicarse con el proceso que realiza el trabajo.

Los muestreos se usaron aquí para una sola cuestión: detectar cuando debería empezar el procedimiento de apagado. Otras tareas, como encolar objetos que puedan ser invocados o buscar los resultados de uno de esos objetos encolado previamente, usan objetos sincronizados de tipo cola. Estos objetos proceden bien del módulo threading o bien del multiprocessing, dependiendo de la implementación del ejecutor que se esté utilizando.

Así que se me ocurrió una solución simple: Sustituí el muestreo por un centinela, el centinela None ya integrado. Cuando una cola recibe None, un trabajador en espera se activa de forma natural y verifica si se debería apagar o no. En el ProcessPoolExecutor hay una pequeña complicación ya que necesitamos activar hasta N procesos trabajadores además del hilo de gestión de colas.

En mi parche inicial, todavía había un tiempo de espera de muestreo muy largo (10 minutos) de manera que los trabajadores pudieran activarse en algún momento. Este largo tiempo de espera existía por si acaso el código contenía bugs y no recibían una notificación de apagado cuando debían a través del ya mencionado centinela. Por curiosidad, me sumergí en el código fuente de multiprocessing y llegué a otra observación interesante: bajo Windows, multiprocessing.Queue.get() con un tiempo de espera no nulo y finito usaba ... muestreo (por lo cual abrí el asunto 11668). Utiliza un tipo de muestreo de alta frecuencia muy interesante, ya que se comienza con un tiempo de espera de un milisegundo el cual se incrementa en cada iteración.

No hace falta mencionar que aunque usara un tiempo de espera muy grande, haría mi parche inútil en Windows ya que la forma en que el tiempo de espera está implementado implicaría activaciones en cada milisegundo. Así que no me quedó más remedio y eliminar el enorme tiempo de muestreo. Mi último parche ni siquiera utiliza un tiempo de espera, y por lo tanto no debería causar activaciones periódicas, independientemente de la plataforma.

Echando un vistazo atrás, antes de Python 3.2, toda estructura para esperas en el módulo threading, y por lo tanto en muchas partes del módulo multiprocessing ya que él mismo utiliza hilos trabajadores para varias tareas, usaba muestreo. Esto se corrigió en el asunto 7316.

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).

¡Bienvenido a Python Insider!

Python Insider es la traducción del blog oficial del equipo de
desarrollo del core de Python. Es un resumen de los asuntos tratados en la
lista de correo de los desarrolladores, con especial hincapié en
los cambios que sobrevendrán a Python. Haremos un resumen de la actividad
de Python-Dev, como la reciente migración a Mercurial, los últimos
Python Enhancement Proposals (PEP) aprobados, cambios en la API
y otros asuntos relevantes en el desarrollo del núcleo de Python.

El blog, más que un substituto, será un complemento de la lista de
correo python-dev y de los blogs personales de los desarrolladores (véase
los enlaces en la barra lateral). Servirá de canal para hablar públicamente
de los proyectos una vez completados, o cuando llegue el momento en el que necesiten
más voluntarios. Agradecemos la discusión en el blog, pero esperamos que aquellos
interesados se una a la lista de correo y puedan seguir las discusiones directamente.

El idioma común a todos los desarrolladores es el inglés, así que siempre que sea posible,
usa los canales originales para que tu opinión pueda llegar a donde debe.

Puedes pensar en este blog como una ventana a la evolución de Python.

Cómo suscribirte

Hay varias formas de seguir Python Insider:

• Planet Python
• En la web
• Feed Atom/RSS
• @PythonInsider en Twitter (en inglés)
• Correo electrónico

Se busca ayuda

Aunque disponemos de un equipo dedicado a escribir entradas para el blog,
estamos buscando a alguien con habilidades en diseño web para trabajar en la
plantilla de Blogger. También estamos buscando gente dispuesta a traducir a otros idiomas.
Si puedes ayudar mejorando el aspecto del blog o traduciendo, por favor
contacta con Doug Hellmann (doug dot hellmann en gmail).