lunes, 8 de agosto de 2011

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.

lunes, 11 de julio de 2011

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:

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

miércoles, 6 de julio de 2011

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.

martes, 14 de junio de 2011

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.

jueves, 19 de mayo de 2011

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.

jueves, 12 de mayo de 2011

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.