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.

lunes, 9 de mayo de 2011

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.

sábado, 7 de mayo de 2011

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!

miércoles, 4 de mayo de 2011

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.



lunes, 2 de mayo de 2011

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