tag:blogger.com,1999:blog-45791657498089488192023-06-21T05:42:43.220+01:00Python Insider ESInformación y noticias sobre el desarrollo de PythonDavidmhhttp://www.blogger.com/profile/14913018830568213369noreply@blogger.comBlogger23125tag:blogger.com,1999:blog-4579165749808948819.post-28069446922158144862011-08-08T20:57:00.001+01:002011-10-25T21:00:21.975+01:00Conoce al equipo: Michael Foord<div class="document" id="conoce-al-equipo-michael-foord">Artículo original: <a class="reference external" href="http://blog.python.org/2011/08/meet-team-michael-foord.html">Meet the Team: Michael Foord</a><br />
<i>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.</i><br />
<table class="docutils field-list" frame="void" rules="none"><col class="field-name"></col> <col class="field-body"></col> <tbody valign="top">
<tr class="field"><th class="field-name">Nombre:</th><td class="field-body">Michael Foord</td> </tr>
<tr class="field"><th class="field-name">Lugar:</th><td class="field-body">Northampton (Reino Unido)</td> </tr>
<tr class="field"><th class="field-name">Página Web:</th><td class="field-body"><a class="reference external" href="http://www.voidspace.org.uk/">http://www.voidspace.org.uk/</a></td> </tr>
</tbody> </table><b>¿Cuánto tiempo llevas usando Python?</b><br />
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.<br />
<b>¿Cuánto tiempo llevas haciendo cambios en el núcleo de Python?</b><br />
Conseguí hacerme mantenedor del núcleo durante el PyCon del 2009. Esto se debió originalmente a mi participación en IronPython.<br />
<b>¿Cómo comenzaste como desarrollador del núcleo? ¿Recuerdas tu primer cambio?</b><br />
Durante los <i>sprints</i> de PyCon 2009, trabajé con Gregory Smith, otro desarrollador del núcleo, para incorporar algunas mejoras a unittest contribución de Google.<br />
<b>¿En qué partes de Python estás trabajando ahora?</b><br />
Después de este trabajo inicial con unittest en el <i>sprint</i> 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.<br />
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.<br />
<b>¿Qué haces con Python cuando no estás trabajando en el desarrollo del núcleo?</b><br />
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.<br />
En mi tiempo libre, trabajo en proyectos como <a class="reference external" href="http://pypi.python.org/pypi/unittest2">unittest2</a> (un <i>backport</i> de las mejoras hechas a unittest para otras plataformas), <a class="reference external" href="http://pypi.python.org/pypi/mock">mock</a> (una biblioteca de pruebas que ofrece objetos mock y soporte para realizar <i>monkey patching</i> en los casos de prueba) y unas cuantas cosas más sin mucha importancia.<br />
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.<br />
<b>¿Qué haces cuando no estás programando?</b><br />
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.<br />
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 <i>geeks</i> 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 <i>gadgets</i>.</div>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-67393614225482538462011-07-11T22:44:00.001+01:002011-07-27T22:46:31.782+01:00Un lanzador python para Windows<div class="document" id="un-lanzador-python-para-windows"> <p>Artículo original: <a class="reference external" href="http://blog.python.org/2011/07/python-launcher-for-windows_11.html">A Python Launcher For Windows</a></p><p>Mark Hammond (autor de <a class="reference external" href="http://sourceforge.net/projects/pywin32/">pywin32</a> y mantenedor de Python para Windows desde hace tiempo) ha escrito <a class="reference external" href="http://www.python.org/dev/peps/pep-0397/">PEP 397</a>, que describe un nuevo lanzador de Python para Windows. Vinay Sanjip (autor del módulo <a class="reference external" href="http://docs.python.org/py3k/library/logging.html">logging</a> de la biblioteca estándar) ha creado recientemente una implementación del lanzador. Se puede descargar desde <a class="reference external" href="https://bitbucket.org/vinay.sajip/pylauncher/downloads">https://bitbucket.org/vinay.sajip/pylauncher/downloads</a></p><p>El lanzador permite que los guiones Python (ficheros <tt class="docutils literal">.py</tt> y <tt class="docutils literal">.pyw</tt>) en Windows especifiquen la versión de Python que debe ser usada, permitiendo el uso simultáneo de Python 2 y 3.</p><p>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).</p><p>Hay disponibles dos versiones del lanzador - <tt class="docutils literal">launcher.msi</tt> que se instala en el directorio <tt class="docutils literal">Archivos de programa</tt>, y <tt class="docutils literal">launchsys.msi</tt> que se instala en el directorio <tt class="docutils literal">System32</tt> de Windows. (Hay versiones de 64 bits para versiones de Windows de 64 bits).</p><div class="section" id="algunos-detalles-acerca-del-lanzador"><h4>Algunos detalles acerca del lanzador</h4><p>La especificación completa del comportamiento del lanzador se encuentra el <a class="reference external" href="http://www.python.org/dev/peps/pep-0397/">PEP 397</a>. Un resumen de los principios básicos:</p><ul class="simple"><li>El lanzador incluye dos ejecutables - <tt class="docutils literal">py.exe</tt> (la versión consola) y <tt class="docutils literal">pyw.exe</tt> (la versión GUI).</li>
<li>El lanzador se registra como gestor para las extensiones de fichero <tt class="docutils literal">.py</tt> (consola) y <tt class="docutils literal">.pyw</tt> (GUI).</li>
<li>Cuando se ejecuta un guión, el lanzador buscará una línea <tt class="docutils literal">#!</tt> (shebang) al estilo Unix en el guión. El lanzador reconoce los siguientes nombres de ejecutables: <tt class="docutils literal">python</tt> (python del sistema por defecto), <tt class="docutils literal">python2</tt> (versión por defecto de Python 2) y <tt class="docutils literal">python3</tt> (versión por defecto de Python 3). Los detalles exactos se pueden personalizar fácilmente por usuario o por máquina.</li>
<li>Cuando se usa de forma independiente, el comando <tt class="docutils literal">py.exe</tt> lanza el intérprete interactivo de Python. Se pueden especificar opciones en la línea de comandos, de forma que <tt class="docutils literal">py <span class="pre">-2</span></tt> lanza Python 2, <tt class="docutils literal">py <span class="pre">-3</span></tt> lanza Python 3, y <tt class="docutils literal">py</tt> la la versión por defecto.</li>
</ul></div><div class="section" id="instrucciones-de-uso-sencillas"><h4>Instrucciones de uso sencillas</h4><p>Cuando se ha instalado, el lanzador se asocia a si mismo con los guiones <tt class="docutils literal">.py</tt> y <tt class="docutils literal">.pyw</tt>. 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 <tt class="docutils literal">.py</tt> a tu variable <tt class="docutils literal">PATHEXT</tt> para que los guiones no se ejecuten en una consola independiente.</p><p>Para especificar que un guión tiene que usar Python 2, simplemente haz que:</p><pre class="literal-block">#!/usr/bin/env python2
</pre><p>sea la primera línea del guión. (Esto es un formato compatible con Unix. Si no necesitas compatibilidad con Unix, utiliza <tt class="docutils literal">#!python2</tt>).</p><p>Por otro lado, si quieres especificar que un guión tiene que usar Python 3, haz que:</p><pre class="literal-block">#!/usr/bin/env python3
</pre><p>sea la primera línea.</p><p>También puedes iniciar el intérprete Python usando cualquiera de los siguientes comandos:</p><pre class="literal-block"># Versión por defecto de Python
py
# Python 2
py -2
# Python 3
py -3
</pre><p>Para que esto funcione el ejecutable <tt class="docutils literal">py.exe</tt> tiene que estar en tu ruta. Esto se configura de forma automática con la versión <tt class="docutils literal">launchsys</tt> del instalador, pero con <tt class="docutils literal">launcher.msi</tt> el directorio de instalación (<tt class="docutils literal"><span class="pre">C:\Archivos</span> de programa\Python Launcher</tt>) debe ser añadido manualmente a <tt class="docutils literal">PATH</tt>.</p></div><div class="section" id="mas-informacion"><h4>Más información</h4><p>Los siguientes hilos de correos en python-dev cubren algunas de las discusiones clave:</p><ul class="simple"><li>Anuncio inicial de Mark del borrador PEP: <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-March/109509.html">http://mail.python.org/pipermail/python-dev/2011-March/109509.html</a></li>
<li>El segundo borrador del PEP: <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-March/109786.html">http://mail.python.org/pipermail/python-dev/2011-March/109786.html</a></li>
<li>Cuestión inicial de Vinay sobre una implementación en C del lanzador: <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-June/112145.html">http://mail.python.org/pipermail/python-dev/2011-June/112145.html</a></li>
<li>Anuncio de Vinay de su implementación en C: <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-July/112184.html">http://mail.python.org/pipermail/python-dev/2011-July/112184.html</a></li>
<li>Llamamiento de Vinay para probadores: <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-July/112251.html">http://mail.python.org/pipermail/python-dev/2011-July/112251.html</a></li>
</ul></div></div>Juan Carlos Coruñahttp://www.blogger.com/profile/17578464077292503137noreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-13313519926624527092011-07-11T21:47:00.003+01:002011-07-21T21:50:23.816+01:00Lanzado CPython 3.2.1<div class="document" id="lanzado-cpython-3-2-1"> <p>Artículo original: <a class="reference external" href="http://blog.python.org/2011/07/cpython-321-released.html">CPython 3.2.1 Released</a></p><p>En nombre del equipo python-dev, el responsable de lanzamientos <a class="reference external" href="http://pythonic.pocoo.org/">Georg Brandl</a> ha anunciado el lanzamiento final de <a class="reference external" href="http://www.python.org/download/releases/3.2.1/">CPython 3.2.1</a>. 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.</p><p>El documento <a class="reference external" href="http://docs.python.org/3.2/whatsnew/3.2.html">What's New</a> lista las nuevas características de la versión 3.2, y el fichero <a class="reference external" href="http://hg.python.org/cpython/file/v3.2.1/Misc/NEWS">Misc/NEWS</a> en el código fuente lista todos los bugs corregidos.</p><p>Si encuentras cualquier problema con esta versión o cualquier otra, por favor repórtalo en <a class="reference external" href="http://bugs.python.org/">http://bugs.python.org/</a>.</p></div>Juan Carlos Coruñahttp://www.blogger.com/profile/17578464077292503137noreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-50669667495431242642011-07-06T10:26:00.000+01:002011-07-21T10:29:35.707+01:00Liberada la versión candidata 3.2.1<div class="document" id="liberada-la-version-candidata-3-2-1">Artículo original: <a class="reference external" href="http://blog.python.org/2011/07/321-release-candidate-2-released.html">3.2.1 Release Candidate 2 Released</a><br />
<br />
Después de un gran mes de junio en el que se han producido varios <a class="reference external" href="http://blog.python.org/2011/06/june-releases-267-272-314.html">lanzamientos</a>, la segunda versión candidata de la línea 3.2.1 ya <a class="reference external" href="http://www.python.org/download/releases/3.2.1/">está preparada</a>. 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.<br />
<div class="section" id="que-se-ha-corregido"><h4>¿Qué se ha corregido?</h4><div class="section" id="e-s"><h5>E/S</h5>El bug <a class="reference external" href="http://bugs.python.org/issue1195">#1195</a> llevaba varios años sin ser resuelto, sin embargo, una pequeña adición para la limpieza de errores antes de llamar a <tt class="docutils literal">fgets</tt> solucionó el problema de interrumpir a <tt class="docutils literal">sys.stdin.read()</tt> con CTRL-D dentro de <tt class="docutils literal">input()</tt>. Se ha realizado una limpieza del sistema <tt class="docutils literal">io</tt> en el bug <a class="reference external" href="http://bugs.python.org/issue12175">#12175</a> en el que el método <tt class="docutils literal">readall</tt> retornando <tt class="docutils literal">None</tt> cuando al llamar a <tt class="docutils literal">read()</tt> esta última retornaba <tt class="docutils literal">None</tt>, y ahora se lanza una excepción <tt class="docutils literal">ValueError</tt> cuando no se puede abrir un fichero.<br />
Aunque esto no es nuevo en la RC2, el bug <a class="reference external" href="http://bugs.python.org/issue11272">#11272</a> es una corrección importante a la función <tt class="docutils literal">input()</tt> para la versión 3.2.1 de Windows al corregir un <tt class="docutils literal">\r</tt> 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.</div><div class="section" id="windows"><h5>Windows</h5>La versión 3.2.0 introdujo una nueva característica para Windows: el soporte para <tt class="docutils literal">os.symlink</tt>. Esto trajo consigo el bug <a class="reference external" href="http://bugs.python.org/issue12084">#12084</a>, <tt class="docutils literal">os.stat</tt> estaba evaluando incorrectamente los enlaces simbólicos en Windows, por lo que se realizaron correcciones en el funcionamiento interno de las diversas funciones <tt class="docutils literal">stat</tt>.<br />
Un usuario informó de la lentitud de <tt class="docutils literal">os.path.isdir</tt>. El hecho de que necesitara de <tt class="docutils literal">os.stat</tt> contribuía a esto, especialmente cuando se evaluaban enlaces simbólicos (los cuales son dos veces más lentos que los ficheros regulares). Aunque <tt class="docutils literal">os.path.isdir</tt> 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 <a class="reference external" href="http://bugs.python.org/issue11583">#11583</a> para que utilice <tt class="docutils literal">GetFileAttributes</tt> se obtiene una pequeña mejoría con la que se puede trabajar.</div><div class="section" id="subprocess"><h5>subprocess</h5>Crear un objeto <tt class="docutils literal">Popen</tt> con argumentos inesperados estaba causando una excepción <tt class="docutils literal">AttributeError</tt>, lo cual fue notificado en el bug <a class="reference external" href="http://bugs.python.org/issue12085">#12085</a> y corregido por la misma persona que informó de este hecho. Debido a un cambio en la versión 3.2.0, <tt class="docutils literal">Popen</tt> no estaba manejando correctamente variables de entorno vacías, específicamente el argumento <tt class="docutils literal">env</tt>. Se creó el bug <a class="reference external" href="http://bugs.python.org/issue12383">#12383</a> para esta cuestión, el cual fue corregido rápidamente.</div><div class="section" id="y-aun-mas"><h5>...¡y aún más!</h5>Para un listado completo de los cambios en la versión 3.2.1 RC2, ¡comprueba <a class="reference external" href="http://hg.python.org/releasing/3.2.1/file/v3.2.1rc2/Misc/NEWS">el registro de cambios</a> y <a class="reference external" href="http://www.python.org/download/releases/3.2.1/">descárgatelo ahora</a>!<br />
Como de costumbre, por favor, informa en <a class="reference external" href="http://bugs.python.org/">http://bugs.python.org</a> de cualquier incidencia que encuentres. Apreciaremos tu ayuda en la creación de versiones robustas de Python.</div></div></div>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-91119160072085133232011-06-14T21:41:00.000+01:002011-07-19T21:42:29.338+01:00Lanzamientos de junio - 2.6.7, 2.7.2, 3.1.4<div class="document" id="lanzamientos-de-junio-2-6-7-2-7-2-3-1-4"> <p>Artículo original: <a class="reference external" href="http://blog.python.org/2011/06/june-releases-267-272-314.html">June Releases - 2.6.7, 2.7.2, 3.1.4</a></p><p>Junio es un gran mes para lanzamientos de Python, con una actualización en cada una de las ramas activas.</p><div class="section" id="id1"><h4>2.6.7</h4><p>Está disponible un nuevo lanzamiento de código fuente de Python <a class="reference external" href="http://www.python.org/download/releases/2.6.7/">2.6.7</a> 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.</p><p>La versión 2.6.7 es el primer lanzamiento en el que se corrige la <a class="reference external" href="http://blog-es.python.org/2011/05/corregida-vulnerabilidad-en-la.html">vulnerabilidad urllib</a> ya comentada. Además se han arreglado una vulnerabilidad DoS en <tt class="docutils literal">smtpd</tt> (cuestión <a class="reference external" href="http://bugs.python.org/issue9129">#9129</a>) y una vulnerabilidad XSS en <tt class="docutils literal">SimpleHTTPServer.list_directory</tt> (cuestión <a class="reference external" href="http://bugs.python.org/issue11442">#11442</a>).</p></div><div class="section" id="id2"><h4>2.7.2</h4><p>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 <a class="reference external" href="http://www.python.org/download/releases/2.7.2/">2.7.2</a>, la cual incluye las correcciones de seguridad mencionadas en la 2.6.7.</p><p>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 <tt class="docutils literal">__abstractmethods__</tt> de una clase, accediendo un fichero mapeado en memoria más allá de su longitud, y varios otros.</p><p>Una corrección en <tt class="docutils literal">getpass</tt> soluciona una regresión en relación a la gestión de CTRL-C y CTRL-Z. <tt class="docutils literal">multiprocessing</tt> 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 <tt class="docutils literal">multiprocessing.Pool</tt>. <tt class="docutils literal">mmap</tt> 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 <tt class="docutils literal">TypeError</tt> en lugar de producir un fallo de segmento cuando se intenta escribir a un mapa no escribible.</p><p>Para una lista completa de cambios, véase <a class="reference external" href="http://hg.python.org/cpython/raw-file/eb3c9b74884c/Misc/NEWS">el fichero de novedades 2.7.2</a>.</p></div><div class="section" id="id3"><h4>3.1.4</h4><p>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.</p><p>La versión 3.1.4 corrige varios problemas con búsquedas <tt class="docutils literal">__dir__</tt> sobre objetos, fechas posteriores al 2038 en la implementación para Windows de <tt class="docutils literal">os.stat</tt> y <tt class="docutils literal">os.utime</tt>, y una serie de limpiezas para 64 bits. Se realizaron una serie de cambios en la biblioteca <tt class="docutils literal">io</tt> para retornar <tt class="docutils literal">None</tt> cuando no se había leído nada y lanzando las excepciones apropiadas en otros puntos. Se corrigieron los argumentos de llamada de <tt class="docutils literal">ctypes</tt> para Windows 64 bits y también se corrigió un fallo en la ejecución.</p><p>Para una lista completa de cambios, véase <a class="reference external" href="http://hg.python.org/cpython/raw-file/feae9f9e9f30/Misc/NEWS">el fichero de novedades 3.1.4</a>.</p></div><div class="section" id="id4"><h4>3.2.1</h4><p>La versión <a class="reference external" href="http://www.python.org/download/releases/3.2.1/">3.2.1</a> 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 <a class="reference external" href="http://bugs.python.org">bugs.python.org</a>.</p></div></div>Juan Carlos Coruñahttp://www.blogger.com/profile/17578464077292503137noreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-59774651004711408892011-05-19T15:12:00.004+01:002011-07-19T15:14:43.905+01:00Traducciones al portugúes, alemán, coreano y chino tradicional<div class="document" id="traducciones-al-portugues-aleman-coreano-y-chino-tradicional"><p>Artículo original: <a class="reference external" href="http://blog.python.org/2011/05/portuguese-german-korean-and.html">Python Insider Translation Project</a></p><p>¡El <a class="reference external" href="http://blog-es.python.org/2011/05/proyecto-de-traduccion-de-python.html">proyecto de traducción</a> de Python Insider continúa creciendo! Hoy lanzamos la versión <a class="reference external" href="http://blog-pt.python.org">portuguesa</a>, <a class="reference external" href="http://blog-de.python.org">alemana</a>, <a class="reference external" href="http://blog-ko.python.org">coreana</a>, y <a class="reference external" href="http://blog-tw.python.org">china tradicional</a> 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 <a class="reference external" href="http://blog.python.org/">Python Insider</a>.</p></div>Juan Carlos Coruñahttp://www.blogger.com/profile/17578464077292503137noreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-55202255259870366262011-05-12T15:30:00.002+01:002011-07-19T15:31:58.051+01:00El nuevo módulo para la gestión de fallos en Python 3.3 ayuda en la depuración<div class="document" id="el-nuevo-modulo-para-la-gestion-de-fallos-en-python-3-3-ayuda-en-la-depuracion"> <p>Artículo original: <a class="reference external" href="http://blog.python.org/2011/05/new-faulthandler-module-in-python-33.html">New faulthandler module in Python 3.3 helps debugging</a></p><p>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.</p><div class="section" id="errores-fatales"><h4>Errores fatales</h4><p>En Python 3.3 se ha introducido un nuevo módulo que te ayudará a resolver este problema: <a class="reference external" href="http://docs.python.org/dev/library/faulthandler.html">faulthandler</a>. <tt class="docutils literal">faulthandler</tt> 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 <tt class="docutils literal">faulthandler.enable()</tt>, incorporando la opción <tt class="docutils literal"><span class="pre">-X</span> faulthandler</tt> al ejecutable Python, o con la variable de entorno <a class="reference external" href="http://docs.python.org/dev/using/cmdline.html#envvar-PYTHONFAULTHANDLER">PYTHONFAULTHANDLER=1</a>. Ejemplo de salida:</p><pre class="literal-block">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
</pre></div><div class="section" id="tiempo-de-espera"><h4>Tiempo de espera</h4><p><tt class="docutils literal">faulthandler</tt> también puede volcar la traza inversa después de un tiempo de espera usando <tt class="docutils literal">faulthandler.dump_tracebacks_later(timeout)</tt>. Llámalo otra vez para reiniciar el temporizador o llama a <tt class="docutils literal">faulthandler.cancel_dump_tracebacks_later()</tt> para parar el temporizador. Ejemplo de salida:</p><pre class="literal-block">Timeout (0:01:00)!
Current thread 0x00007f987d459700:
File "Lib/test/crashers/infinite_loop_re.py", line 20 in <module>
</pre><p>Usa la opción <tt class="docutils literal">repeat=True</tt> para volcar la traza inversa cada <tt class="docutils literal">timeout</tt> segundos, o <tt class="docutils literal">exit=True</tt> para salir del programa inmediatamente de forma insegura, p. ej. no volcando el buffer de archivos a disco.</p></div><div class="section" id="senal-de-usuario"><h4>Señal de usuario</h4><p>Si tienes acceso a la maquina en la cual se está ejecutando el programa, puedes usar <tt class="docutils literal">faulthandler.register(signal)</tt> para instalar un gestor de señal que vuelque la traza inversa cuando se reciba <tt class="docutils literal">signal</tt>. En UNIX, por ejemplo, puedes usar la señal <tt class="docutils literal">SIGUSR1</tt>: <tt class="docutils literal">kill <span class="pre">-USR1</span> <pid></tt> volcará la traza inversa actual. Esta funcionalidad no está disponible bajo Windows. Ejemplo de salida:</p><pre class="literal-block">Current thread 0x00007fdc3da74700:
File "Lib/test/crashers/infinite_loop_re.py", line 19 in <module>
</pre><p>Otra posibilidad es llamar explícitamente a <tt class="docutils literal">faulthandler.dump_traceback()</tt> en tu programa.</p></div><div class="section" id="temas-de-seguridad-y-el-fichero-de-salida"><h4>Temas de seguridad y el fichero de salida</h4><p><tt class="docutils literal">faulthandler</tt> está deshabilitado por defecto por razones de seguridad, principalmente porque almacena el descriptor de fichero de <tt class="docutils literal">sys.stderr</tt> y escribe las trazas inversas en este descriptor de fichero. Si se cierra <tt class="docutils literal">sys.stderr</tt> 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, <tt class="docutils literal">faulthandler</tt> escribe las trazas inversas en <tt class="docutils literal">sys.stderr</tt>, pero puedes especificar otro fichero. Para más información, consulta la <a class="reference external" href="http://docs.python.org/dev/library/faulthandler.html#file-descriptor-issue">documentación de faulthandler</a>.</p></div><div class="section" id="modulo-de-terceros-para-versiones-antiguas-de-python"><h4>Módulo de terceros para versiones antiguas de Python</h4><p><tt class="docutils literal">faulthandler</tt> también es mantenido como un módulo de terceros para Python 2.5 hasta 3.2 <a class="reference external" href="http://pypi.python.org/pypi/faulthandler/">mediante PyPi</a>. La mayor diferencia entre el módulo Python 3.3 y el módulo de terceros es la implementación de <tt class="docutils literal">dump_tracebacks_later()</tt>: Python 3.3 usa un hilo con un tiempo de espera en un bloqueo, por otro lado el de terceros usa <tt class="docutils literal">SIGALRM</tt> y <tt class="docutils literal">alarm()</tt>.</p><p>El tiempo de espera del bloqueo (que es una nueva funcionalidad de Python 3.3), tiene una resolución de un microsegundo. El temporizador <tt class="docutils literal">alarm()</tt> usado en versiones anteriores tiene una resolución de un segundo, y la señal <tt class="docutils literal">SIGALRM</tt> puede interrumpir la llamada actual al sistema que fallará con un error <tt class="docutils literal">EINTR</tt>.</p></div><div class="section" id="exito-rapido"><h4>Éxito rápido</h4><p>El nuevo módulo <tt class="docutils literal">faulthandler</tt> ya ha sido de ayuda en el rastreo de condiciones de carrera en nuestros buildbots. Esperamos que te ayude también en tus programas.</p></div></div>Juan Carlos Coruñahttp://www.blogger.com/profile/17578464077292503137noreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-43908663263153481112011-05-09T14:59:00.005+01:002011-07-19T15:04:30.847+01:00Traducciones a rumano y a chino simplificado<div class="document" id="traducciones-a-rumano-y-a-chino-simplificado"><p>Artículo original: <a class="reference external" href="http://blog.python.org/2011/05/romanian-and-simplified-chinese.html">Romanian and Simplified Chinese Translations</a></p><p>El equipo de Python Insider se complace en anunciar hoy dos nuevos blogs. Al <a class="reference external" href="http://blog-es.python.org/2011/05/proyecto-de-traduccion-de-python.html">proyecto de traducción</a> se han unido traductores de <a class="reference external" href="http://blog-ro.python.org">rumano</a> y de <a class="reference external" href="http://blog-cn.python.org">chino simplificado</a>, 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 <a class="reference external" href="http://blog.python.org/">Python Insider</a>.</p></div>Juan Carlos Coruñahttp://www.blogger.com/profile/17578464077292503137noreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-18752700128991253242011-05-07T11:22:00.001+01:002011-07-18T11:24:08.862+01:00Migración de Jython a Mercurial<div class="document" id="migracion-de-jython-a-mercurial">Artículo original: <a class="reference external" href="http://blog.python.org/2011/05/jython-migrates-to-mercurial.html">Jython Migrates to Mercurial</a><br />
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.<br />
El nuevo repositorio oficial de Jython está ahora alojado en:<br />
<a class="reference external" href="http://hg.python.org/jython">http://hg.python.org/jython</a><br />
con un <a class="reference external" href="http://bitbucket.org/jython/jython">espejo BitBucket</a> para hacer ramas de forma fácil.<br />
Existe también un repositorio mayor de solo lectura con posibilidades de realizar ramas (convertidas a marcas de Mercurial). Este repositorio está alojado en <a class="reference external" href="http://hg.python.org/jython-fullhistory">http://hg.python.org/jython-fullhistory</a><br />
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!</div>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-43879456009091392202011-05-04T19:58:00.000+01:002011-05-25T14:18:38.052+01:00Python 3.3 no ofrecerá soporte para OS/2, Windows 2000 y VMS<div class="document" id="python-3-3-no-ofrecera-soporte-para-os-2-windows-2000-y-vms"><br />
<br />
Artículo original: <a class="reference external" href="http://blog.python.org/2011/05/python-33-to-drop-support-for-os2.html">Python 3.3 to Drop Support for OS/2, Windows 2000, and VMS</a><br />
<br />
De vez en cuando llega el momento en que se debe limpiar la lista de los<br />
sistemas operativos soportados para ser realista en el uso de estos<br />
sistemas. Además de esto, el número de desarrolladores especializados<br />
en una plataforma es también importante, ya que se necesita que haya<br />
siempre alguien con los conocimientos adecuados para ofrecer un producto<br />
de calidad. Otros factores como la antiguedad del sistema operativo y el<br />
estorbo que pueden suponer en futuros desarrollos también tienen su peso<br />
en estas decisiones.<br />
<br />
<a class="reference external" href="http://www.haypocalc.com/wiki/Victor_Stinner">Victor Stinner</a> propuso recientemente <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-April/110872.html">eliminar el soporte de OS/2 y VMS</a><br />
para CPython un año después de la <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2010-April/099471.html">pregunta original</a> sobre el<br />
soporte de OS/2. La propuesta original de Victor llegó mientras trabaja<br />
incansablemente en Unicode, especialmente en una cuestión relacionada<br />
con el soporte de las variables de entorno en <a class="reference external" href="http://docs.python.org/library/os#os.execvpe">os.execvpe()</a> a través del<br />
manejador <a class="reference external" href="http://www.python.org/dev/peps/pep-0383/">PEP 383</a> . Tanto OS/2 como VMS no tienen actualmente<br />
representantes en el equipo de desarrollo y no se realizan pruebas durante<br />
las fase de liberación de versiones.<br />
<br />
El proceso de redacción de esta entrada <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-May/111159.html">me hizo pensar</a> sobre una<br />
<a class="reference external" href="http://mail.python.org/pipermail/python-dev/2010-March/098074.html">discusión previa</a> sobre eliminar Windows 2000, la cual parece haberse<br />
caído del todo. Los sistemas que ajustaban <tt class="docutils literal">COMSPEC</tt> a <tt class="docutils literal">command.com</tt><br />
también fueron considerados para su eliminación. <a class="reference external" href="http://hg.python.org/peps/rev/b9390aa12855">Actualmente</a>, ambos<br />
se han unido a OS/2 y VMS. Windows 2000 está preparado para ser eliminado<br />
con el fin de facilitar el desarrollo, eliminando el hecho de estar<br />
pendientes de las APIs oficiales en un sistema operativo que alcanzó el<br />
final de su ciclo de vida en 2010.<br />
<br />
Para eliminar el soporte de estos sistemas, Victor y yo comenzamos por<br />
actualizar la <a class="reference external" href="http://www.python.org/dev/peps/pep-0011/">PEP 11</a>.<br />
<br />
<div class="section" id="pep-11"><br />
<h4>PEP 11</h4><br />
Esta PEP define los sistemas opertativos que ya no son soportados y explica el<br />
proceso de adición de un nuevo sistema a la lista.<br />
<br />
Una vez se decide que se puede comenzar el proceso de eliminación de un<br />
sistema operativo, se anuncia oficialmente que ya no está soportado. Este<br />
anuncio, tradicionalmente, va en la versión en desarrollo, de forma que<br />
la eliminación del soporte de OS/2, Windows 2000 y VMS comienza con<br />
Python 3.3.<br />
<br />
El primer paso es sencillo, no hay nada más que levanter la bandera blanca.<br />
Es una señal de que nadie mantiene el código ni asegura una versión de<br />
calidad. Los cambios en compilación e instalación se realizan para<br />
avisar a los usuarios de que esas plataformas ya no están soportadas. Una<br />
nota se muestra en el listado del documento "<a class="reference external" href="http://docs.python.org/dev/whatsnew/3.3.html#unsupported-operating-systems">What's New</a>" listando las<br />
nuevas plataformas sin soporte.<br />
<br />
Después de un ciclo de liberación sin soporte, la versión obtiene el<br />
visto bueno a una eliminación de código. En este caso, el código puede ser<br />
eliminado en la versión 3.4. No se realizará (probablemente) una<br />
eliminación completa, sin embargo los desarrolladores que trabajen en el<br />
código pueden eliminar cualquier bloque <tt class="docutils literal">#ifdef</tt>, secciones<br />
<tt class="docutils literal">configure</tt> o código desactualizado.<br />
<br />
</div><br />
<div class="section" id="que-puedes-hacer"><br />
<h4>Qué Puedes Hacer</h4><br />
Si eres un usario de OS/2 o VMS, hay algunas cosas que puedes hacer para<br />
evitar que tu plataforma deje de estar soportada.<br />
<br />
<div class="section" id="hazte-mantenedor"><br />
<h5>Hazte Mantenedor</h5><br />
Nada dice más de un soporte que ser un desarrollador en activo. Andrew<br />
MacIntyre ha sido el mantenedor de OS/2 durante algún tiempo, y anunció<br />
durante la primera consulta sobre OS/2 de Victor que en este sistema<br />
se quiere integrar el soporte Unicode, de modo que se trata de un área<br />
en la que hay que centrarse. Parece que VMS tiene algún soporte externo<br />
a través de <a class="reference external" href="http://www.vmspython.org/">http://www.vmspython.org</a>, pero tal y como se ha discutido en<br />
la <a class="reference external" href="http://bugs.python.org/issue11918">issue 11918</a>, alguien debe colaborar para que el soporte de VMS siga<br />
realizándose por el equipo principal de desarrollo.<br />
<br />
Si estás interesado en hacerte cargo de cualquiera de estas plataformas,<br />
lee la <a class="reference external" href="http://docs.python.org/devguide">guía del desarrollador</a> para ver el estado de los procesos de<br />
desarrollo actuales.<br />
<br />
</div><br />
<div class="section" id="contribuye-con-una-version-esclava"><br />
<h5>Contribuye con una versión esclava</h5><br />
Con un desarrollador activo, una plataforma tiene mayor probabilidad de<br />
sobrevivir. Con una versión esclava, la plataforma tendrá aún más<br />
posibilidades no sólo en lo que a supervivencia se refiere, sino también<br />
en lo referente a la calidad.<br />
<br />
Python usa <a class="reference external" href="http://trac.buildbot.net/">Buildbot</a> para la integración continuada, y se<br />
<a class="reference external" href="http://www.python.org/dev/buildbot/">ofrecen actualmente</a> versiones esclavas para Linux, Mac, Windows y Open<br />
Indiana (Solaris), para varias versiones, arquitecturas y configuraciones.<br />
El hecho de donar una máquina para la flota de construcción de OS/2 o VMS<br />
podría permitir que estas plataformas reciban la misma atención de las que<br />
otras plataformas más mayoritarias reciben.<br />
<br />
Si puedes donar tiempo o hardware para mantener vivos a OS/2 y VMS,<br />
contacta con la lista de correo <a class="reference external" href="http://mail.python.org/mailman/listinfo/python-dev">python-dev</a> para coordinar tus<br />
esfuerzos.<br />
<br />
</div><br />
</div><br />
</div>Davidmhhttp://www.blogger.com/profile/14913018830568213369noreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-43733538796619402782011-05-02T14:55:00.002+01:002011-07-19T14:56:22.146+01:00Proyecto de traducción de Python Insider<div class="document" id="proyecto-de-traduccion-de-python-insider"> <p>Artículo original: <a class="reference external" href="http://blog.python.org/2011/05/python-insider-translation-project.html">Python Insider Translation Project</a></p><p>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: <a class="reference external" href="http://blog-ja.python.org/">japonés</a> y <a class="reference external" href="http://blog-es.python.org/">español</a>.</p><p>Las traducciones estarán un poco retrasadas con respecto a las publicaciones en <a class="reference external" href="http://blog.python.org/">Python Insider</a>, pero estarán lo más actualizadas posible.</p><div class="section" id="necesitamos-ayuda"><h4>Necesitamos ayuda</h4><p>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).</p></div></div>Juan Carlos Coruñahttp://www.blogger.com/profile/17578464077292503137noreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-59905479516650991902011-04-28T22:21:00.000+01:002011-05-25T14:14:56.618+01:00Conoce al equipo: Brian Curtin<div class="document" id="conoce-al-equipo-brian-curtin">Artículo original: <a class="reference external" href="http://blog.python.org/2011/04/meet-team-brian-curtin.html">Meet the Team: Brian Curtin</a><br />
<i>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.</i><br />
<table class="docutils field-list" frame="void" rules="none"><col class="field-name"></col> <col class="field-body"></col> <tbody valign="top">
<tr class="field"><th class="field-name">Nombre:</th><td class="field-body">Brian Curtin</td> </tr>
<tr class="field"><th class="field-name">Lugar:</th><td class="field-body">Chicago, IL</td> </tr>
<tr class="field"><th class="field-name">Página Web:</th><td class="field-body"><a class="reference external" href="http://blog.briancurtin.com/">http://blog.briancurtin.com/</a></td> </tr>
</tbody> </table><b>¿Cuánto tiempo llevas usando Python?</b><br />
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.<br />
<b>¿Cuánto tiempo llevas haciendo cambios en el núcleo de Python?</b><br />
Desde hace más o menos un año. El 24 de marzo hará una año de pertenencia al grupo.<br />
<b>¿Cómo comenzaste como desarrollador del núcleo? ¿Recuerdas tu primer cambio?</b><br />
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.<br />
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.<br />
<b>¿En qué partes de Python estás trabajando ahora?</b><br />
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.<br />
<b>¿Qué haces con Python cuando no estás trabando en el desarrollo del núcleo?</b><br />
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.<br />
<b>¿Qué haces cuando no estás programando?</b><br />
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.</div>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-64508105542278479132011-04-21T16:22:00.000+01:002011-07-18T16:25:05.016+01:00Conoce al equipo: Nick Coghlan<div class="document" id="conoce-al-equipo-nick-coghlan">Artículo original: <a class="reference external" href="http://blog.python.org/2011/04/meet-team-nick-coghlan.html">Meet the Team: Nick Coghlan</a><br />
<i>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.</i><br />
<table class="docutils field-list" frame="void" rules="none"><col class="field-name"></col> <col class="field-body"></col> <tbody valign="top">
<tr class="field"><th class="field-name">Nombre:</th><td class="field-body">Nick Coghlan</td> </tr>
<tr class="field"><th class="field-name">Lugar:</th><td class="field-body">Brisbane, Australia</td> </tr>
<tr class="field"><th class="field-name">Página Web:</th><td class="field-body"><a class="reference external" href="http://www.boredomandlaziness.org/">http://www.boredomandlaziness.org</a></td> </tr>
</tbody> </table><b>¿Cuánto tiempo llevas usando Python?</b><br />
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.<br />
<b>¿Cuánto tiempo llevas haciendo cambios en el núcleo de Python?</b><br />
Guido me dio acceso en 2005 para actualizar la PEP 343 (principalmente para poner en marcha el método de contexto)<br />
<b>¿Cómo comenzaste como desarrollador del núcleo? ¿Recuerdas tu primer cambio?</b><br />
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.<br />
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.<br />
<b>¿En qué partes de Python estás trabajando ahora?</b><br />
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.<br />
<b>¿Qué haces con Python cuando no estás trabajando en el desarrollo del núcleo?</b><br />
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.<br />
<b>¿Qué haces cuando no estás programando?</b><br />
Taekwondo, videojuegos, fútbol, lectura, etc, etc...</div>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-49927662769811333022011-04-19T16:54:00.000+01:002011-07-18T16:55:26.024+01:00Nuevo diseño del Blog<div class="document" id="nuevo-diseno-del-blog">Si usas un lector de noticias para estar al día de <a class="reference external" href="http://blog.python.org/">Python Insider</a>, puede que no hayas notado el nuevo diseño de pagina que <a class="reference external" href="http://twitter.com/sigviper">Marcin Wojtczuk</a> 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.<br />
¡Muchas gracias por tu tiempo y esfuerzos Marcin!</div>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-8591971711818598422011-04-14T16:58:00.000+01:002011-05-25T14:22:36.156+01:00Corregida vulnerabilidad en la seguridad de urllib/urllib2<div class="document" id="corregida-vulnerabilidad-en-la-seguridad-de-urllib-urllib2">Artículo original: <a class="reference external" href="http://blog.python.org/2011/04/urllib-security-vulnerability-fixed.html">urllib Security Vulnerability Fixed</a><br />
Guido van Rossum <a class="reference external" href="http://hg.python.org/cpython/rev/a778b963eae3">publicó recientemente una corrección</a> 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.<br />
<div class="section" id="informar-de-un-fallo"><h4>Informar de un fallo</h4>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.<br />
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 <a class="reference external" href="mailto:security@python.org">security@python.org</a>.<br />
Recientemente Niels Heinen del Equipo de Seguridad de Google, <a class="reference external" href="http://bugs.python.org/issue11662#msg131981">presentó un buen informe</a>. Descubrió un fallo en el manejo de redirecciones HTTP 302 en los módulos de las bibliotecas estándar <a class="reference external" href="http://docs.python.org/library/urllib">urllib</a> y <a class="reference external" href="http://docs.python.org/library/urllib2">urllib2</a>. 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.<br />
En primer lugar, ya que <tt class="docutils literal">urllib</tt>/<tt class="docutils literal">urllib2</tt> ofrecen un manejador para el esquema URL <tt class="docutils literal"><span class="pre">file://</span></tt>, una redirección a <tt class="docutils literal"><span class="pre">file:///etc/passwd</span></tt> podría exponer información de contraseñas. Neils también explicó que la redirección a un dispositivo del sistema como <tt class="docutils literal"><span class="pre">file:///dev/zero</span></tt> podría generar un agotamiento de los recursos, desembocando en una denegación de servicio.</div><div class="section" id="gestionar-un-informe"><h4>Gestionar un informe</h4>Debido a la naturaleza sensible de los informes de seguridad, la lista <a class="reference external" href="mailto:security@python.org">security@python.org</a> 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 <a class="reference external" href="http://www.python.org/news/security/">noticias sobre seguridad</a> para detalles sobre OpenPGP.<br />
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 <a class="reference external" href="http://bugs.python.org/issue11662">issue #11662</a>, completándolo con un parche inicial.</div><div class="section" id="corregir-el-fallo"><h4>Corregir el fallo</h4>Lo que no hace el parche de Guido es restringir la redirección a los esquemas URL <tt class="docutils literal"><span class="pre">http://</span></tt>, <tt class="docutils literal"><span class="pre">https://</span></tt> y <tt class="docutils literal"><span class="pre">ftp://</span></tt>. 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.<br />
Para Python 2.x, el método <tt class="docutils literal">redirect_internal</tt> de <a class="reference external" href="http://docs.python.org/library/urllib#urllib.FancyURLopener">FancyURLopener</a> arroja ahora una excepción <tt class="docutils literal">IOError</tt> cuando se solicita la realización de una redirección a un esquema inapropiado. El método <tt class="docutils literal">http_error_302</tt> de <a class="reference external" href="http://docs.python.org/library/urllib2#httpredirecthandler-objects">HTTPRedirectHandler</a> hace lo mismo, arrojando <tt class="docutils literal">HTTPError</tt> únicamente. En Python 3, las mismas correcciones se realizaron en <a class="reference external" href="http://docs.python.org/dev/library/urllib.request">urllib.request</a>. Se incluyeron con el parche dos pruebas las cuales ponen en práctica la redirección en esquemas válidos e inválidos.<br />
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.</div></div>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-39820748807746506392011-04-11T17:08:00.000+01:002011-07-20T17:09:25.817+01:00Conoce al equipo: Tarek Ziadé<div class="document" id="conoce-al-equipo-tarek-ziade">Artículo original: <a class="reference external" href="http://blog.python.org/2011/04/meet-team-tarek-ziade.html">Meet the Team: Tarek Ziadé</a><br />
<i>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.</i><br />
<table class="docutils field-list" frame="void" rules="none"><col class="field-name"></col> <col class="field-body"></col> <tbody valign="top">
<tr class="field"><th class="field-name">Nombre:</th><td class="field-body">Tarek Ziadé</td> </tr>
<tr class="field"><th class="field-name">Lugar:</th><td class="field-body">Turcey cerca de Dijon, Borgoña (Francia)</td> </tr>
<tr class="field"><th class="field-name">Página Web:</th><td class="field-body"><a class="reference external" href="http://ziade.org/">http://ziade.org</a></td> </tr>
</tbody> </table><b>¿Cuánto tiempo llevas usando Python?</b><br />
Alrededor de diez años.<br />
<b>¿Cuánto tiempo llevas haciendo cambios en el núcleo de Python?</b><br />
Desde el 21 de diciembre de 2008.<br />
<b>¿Cómo comenzaste como desarrollador del núcleo? ¿Recuerdas tu primer cambio?</b><br />
Comencé a trabajar como desarrollador del núcleo para mantener Distutils y hacerlo evolucionar.<br />
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.<br />
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.<br />
<b>¿En qué partes de Python estás trabajando ahora?</b><br />
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.<br />
<b>¿Qué haces con Python cuando no estás trabajando en el desarrollo del núcleo?</b><br />
Trabajo en el equipo de servicio de Mozilla, en el cual construyo servicios web usando Python<br />
<b>¿Qué haces cuando no estás programando?</b><br />
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.</div>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-58338009195471646472011-04-06T00:08:00.000+01:002011-07-15T00:12:34.553+01:00Formalizando las Directrices de Control de Cambios de AST<div class="document" id="formalizando-las-directrices-de-control-de-cambios-de-ast">Artículo original: <a class="reference external" href="http://blog.python.org/2011/04/formalizing-ast-change-control-policy.html">Formalizing the AST Change Control Policy</a><br />
Python ofrece un árbol de sintaxis abstracta (AST) que representa la forma compilada del código fuente Python en el <a class="reference external" href="http://docs.python.org/py3k/library/ast.html">módulo AST</a>. 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).<br />
Mientras que el código Python se define en la <a class="reference external" href="http://docs.python.org/py3k/reference/index.html">referencia del lenguaje</a>, el módulo AST es un detalle de la implementación CPython y no es necesaria en otras implementaciones de Python.<br />
<div class="section" id="compatibilidad-del-ast"><h4>Compatibilidad del AST</h4>Como parte del <a class="reference external" href="http://bugs.python.org/issue11549">trabajo</a> 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 <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-April/110399.html">preguntó</a> en python-dev: ¿Es necesario, cuando cambie el AST, asegurar la compatibilidad hacia atrás?<br />
El consenso general resultó en que <i>no</i> era necesaria esta compatibilidad. El módulo AST dispone de una constante <tt class="docutils literal">ast.__version__</tt>, 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.</div><div class="section" id="otras-implementaciones-python"><h4>Otras implementaciones Python</h4>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 <tt class="docutils literal">ast.__version__</tt> cambie, el AST deberá ser modificado para que sea compatible.<br />
Un aspecto que salió a la luz, es que el conjunto de casos de prueba en <tt class="docutils literal">test_ast.py</tt> 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 <tt class="docutils literal">test_ast.py</tt>!</div><div class="section" id="que-ocurrira-a-continuacion"><h4>¿Qué ocurrirá a continuación?</h4>El <a class="reference external" href="http://bugs.python.org/issue11549">parche</a> 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 <i>cambiará</i> de forma que sea incompatible. La constante <tt class="docutils literal">ast.__version__</tt> 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.<br />
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 <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-April/110399.html">discusión que se mantiene en python-dev</a>.</div></div>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-41279535691629632542011-04-01T22:10:00.000+01:002011-07-20T18:06:17.288+01:00Thomas Heller renuncia como mantenedor de ctypes<div class="document" id="thomas-heller-renuncia-como-mantenedor-de-ctypes">Artículo original: <a class="reference external" href="http://blog.python.org/2011/04/thomas-heller-steps-down-as-ctypes.html">Thomas Heller Steps Down as ctypes Maintainer</a><br />
La comunidad de desarrollo de Python le debe un gran agradecimiento al mantenedor durante mucho tiempo de <a class="reference external" href="http://docs.python.org/library/ctypes">ctypes</a>, Thomas Heller. A principios de este mes, Thomas <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-March/109395.html">anunció su marcha</a> del proyecto CPython, el hogar de su biblioteca <tt class="docutils literal">ctypes</tt> desde Python 2.5.<br />
Tuve la oportunidad de hablar con Thomas y él me contó su historia con Python y sus proyectos <tt class="docutils literal">ctypes</tt> y <tt class="docutils literal">py2exe</tt>.<br />
<div class="section" id="python"><h4>Python</h4>En 1999 Thomas se topó con el libro <a class="reference external" href="http://www.amazon.com/Programming-Python-Mark-Lutz/dp/0596009259">Programming Python</a> 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 <a class="reference external" href="http://groups.csail.mit.edu/mac/projects/scheme/">Scheme</a> como lenguaje de extensión de un gran programa en C que había escrito para Windows.<br />
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 <tt class="docutils literal">distutils</tt>. Su interés en <tt class="docutils literal">distutils</tt> le llevo en última instancia a la creación del comando <tt class="docutils literal">bdist_wininst</tt> 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.</div><div class="section" id="py2exe"><h4>py2exe</h4>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 <tt class="docutils literal">squeeze</tt> de Fredrik Lundh y <tt class="docutils literal">sqfreeze</tt> de Christian Tismer, y Thomas contribuyó varios parches al proyecto <a class="reference external" href="http://davidf.sjsoft.com/mirrors/mcmillan-inc/install1.html">Installer</a> de McMillan.<br />
Su interés en <tt class="docutils literal">distutils</tt> llevó a Thomas a considerar portar <tt class="docutils literal">Installer</tt> a una extensión de la biblioteca de empaquetamiento. Sin embargo, terminó reescribiendo las fuentes para hacer uso del marco de trabajo <tt class="docutils literal">distutils</tt> ya existente. Al final, eligió el simple y a la par descriptivo nombre de <tt class="docutils literal">py2exe</tt> para el proyecto.</div><div class="section" id="ctypes"><h4>ctypes</h4>La idea para <tt class="docutils literal">ctypes</tt> vino de la necesidad de llegar más allá de lo que aportaba <a class="reference external" href="http://sourceforge.net/projects/pywin32/">pywin32</a> 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.<br />
<tt class="docutils literal">ctypes</tt> 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 <a class="reference external" href="http://python.net/crew/theller/">página Starship</a> se convirtió en una biblioteca ampliamente usada en poco tiempo.<br />
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 <a class="reference external" href="http://sourceware.org/libffi/">libffi</a> al proyecto, la cual empezó a usar en Windows para reemplazar su implementación de bajo nivel.<br />
En 2006 se liberó la versión 1.0 para <tt class="docutils literal">ctypes</tt>, 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, <tt class="docutils literal">ctypes</tt> fue entonces empaquetada con Python para estar disponible a una audiencia mucho más amplia.<br />
Mucha gente ayudó a que <tt class="docutils literal">ctypes</tt> 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.</div><div class="section" id="un-nuevo-mantenedor-de-ctypes"><h4>Un nuevo mantenedor de ctypes</h4>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 <a class="reference external" href="http://docs.python.org/devguide">developer guide</a> y busca en <a class="reference external" href="http://bugs.python.org/">el bug tracker</a> para más información.<br />
<b>Actualización:</b> Corregidos algunos enlaces.</div></div>Juan Carlos Coruñahttp://www.blogger.com/profile/17578464077292503137noreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-21523085071158531672011-03-30T17:02:00.000+01:002011-07-20T17:03:29.765+01:00Conoce al equipo: Benjamin Peterson<div class="document" id="conoce-al-equipo-benjamin-peterson">Artículo original: <a class="reference external" href="http://blog.python.org/2011/03/meet-team-benjamin-peterson.html">Meet the Team: Benjamin Peterson</a><br />
<i>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.</i><br />
<table class="docutils field-list" frame="void" rules="none"><col class="field-name"></col> <col class="field-body"></col> <tbody valign="top">
<tr class="field"><th class="field-name">Nombre:</th><td class="field-body">Benjamin Peterson</td> </tr>
<tr class="field"><th class="field-name">Lugar:</th><td class="field-body">Minnesota (Estados Unidos)</td> </tr>
<tr class="field"><th class="field-name">Página Web:</th><td class="field-body"><a class="reference external" href="http://benjamin-peterson.org/">http://benjamin-peterson.org/</a></td> </tr>
<tr class="field"><th class="field-name">Blog:</th><td class="field-body"><a class="reference external" href="http://pybites.blogspot.com/">http://pybites.blogspot.com/</a></td> </tr>
</tbody> </table><b>¿Cuánto tiempo llevas usando Python?</b><br />
Tres años y medio.<br />
<b>¿Cuánto tiempo llevas haciendo cambios en el núcleo de Python?</b><br />
Hará tres años exactamente el próximo 25 de marzo.<br />
<b>¿Cómo comenzaste como desarrollador del núcleo? ¿Recuerdas tu primer cambio?</b><br />
Mi primer propuesta fue <a class="reference external" href="http://bugs.python.org/issue1828">rechazada personalmente por Guido</a>. Afortunadamente, insistí y conseguí que algunos de mis parches fueran aceptados. Creo que mi primer cambio fue el reordenamiento del fichero Misc/ACKS.<br />
<b>¿En qué partes de Python estás trabajando ahora?</b><br />
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!<br />
<b>¿Qué haces con Python cuando no estás trabajando en el desarrollo del núcleo?</b><br />
¡Lo uso para implementar un intérprete de Python (<a class="reference external" href="http://pypy.org/">http://pypy.org</a>)!. Créeme, en el fondo soy un implementador de Python. :) Soy el creador de six (<a class="reference external" href="http://pypi.python.org/pypi/six">http://pypi.python.org/pypi/six</a>), una biblioteca de compatibilidad de Python 2 y 3.<br />
<b>¿Qué haces cuando no estás programando?</b><br />
Compongo música, toco el clarinete y leo libros de matemáticas. También salgo al campo de vez en cuando.</div>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-24406460137839229802011-03-28T02:29:00.000+01:002011-05-25T14:21:24.056+01:00Características de Python 2.7 obsoletas en 3.x<div class="document" id="caracteristicas-de-python-2-7-obsoletas-en-3-x"><br />
<br />
Una reciente <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-March/109010.html">discusión en python-dev</a><br />
puso de manifiesto un fallo en la actual política de obsolescencia (deprecation)<br />
adoptada por los desarrolladores en la migración de 2.7 a la nueva 3.x.<br />
En consecuencia, el equipo de desarrollo ha tenido que modificar su<br />
política para tener en cuenta que los usuarios migrarán directamente de Python 2.7<br />
a la última versión de 3.x, sin pasar por versiones intermedias.<br />
<br />
<div class="section" id="antecedentes"><br />
<h4>Antecedentes</h4><br />
Python tiene un fuerte compromiso con la compatibilidad con versiones anteriores.<br />
No se permite ningún cambio a menos que esté de acuerdo con las directrices de compatibilidad,<br />
que en esencia dicen que programas correctos no deben fallar en versiones más modernas.<br />
Sin embargo, esto no es siempre posible, por ejemplo, cuando una API deja de funcionar y debe ser<br />
reemplazada por algo nuevo. En este caso, Python sigue una política de obsolescencia basada<br />
en un periodo de transición de un año en el que las características a renovar son consideradas<br />
formalmente obsoletas. En el periodo intermedio, se debe emitir un aviso (<tt class="docutils literal">deprecation warning</tt>)<br />
de forma que los programadores tengan tiempo de actualizar su código. Los detalles completos<br />
de la política de Python están documentados en el <a class="reference external" href="http://www.python.org/dev/peps/pep-0005/">PEP 5</a>. Los cambios sólo se hacen<br />
en las versiones nuevas y normalmente pasan 18 meses entre versiones; ergo la norma es<br />
una versión en el periodo.<br />
<br />
La única excepción ha sido Python 3. La nueva rama ha sido específicamente creada para permitir cambios que<br />
rompieran la compatibilidad, permitiendo así a los desarrolladores de Python corregir problemas que,<br />
simplemente, no podían solucionarse dentro de la política actual. Por ejemplo, hacer las cadenas<br />
Unicode por defecto y devolver iteradores en lugar de listas.<br />
<br />
</div><br />
<div class="section" id="lineas-paralelas-de-desarrollo"><br />
<h4>Líneas paralelas de desarrollo</h4><br />
Sabiendo que la transción a Python 3 llevaría tiempo (unos 5 años, según varias estimaciones),<br />
habría cierto desarrollo paralelo entre 2 y 3.<br />
<br />
Con Python 2.7 como versión final de Python 2, se acordó que el periodo de mantenimiento<br />
se extendería por un periodo substancial. Tarde o temprano, los desarrolladores que quieran<br />
migrar a versiones más nuevas deberán dar el salto a Python 3.<br />
<br />
He aquí uno de los problemas...<br />
<br />
</div><br />
<div class="section" id="obsolescencias-sorpresa"><br />
<h4>Obsolescencias sorpresa</h4><br />
En un hilo en python-dev`<<a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-March/109010.html">http://mail.python.org/pipermail/python-dev/2011-March/109010.html</a>>`__,<br />
se señaló que una función específica de la API C, <tt class="docutils literal">PyCObject_AsVoidPtr</tt>, había sido eliminada<br />
con lo que parecían insuficientes avisos. Y, sin embargo, la política adoptada se supone que debería<br />
proteger contra eso. ¿Qué pasó?<br />
<br />
El cambio fue parte de una migración mayor desde una API más antigua, <tt class="docutils literal">PyCObject</tt>, a una nueva y<br />
mejorada, <tt class="docutils literal">PyCapsule</tt>. El problema es que <tt class="docutils literal">PyCObject</tt> es la predeterminada, y desde luego,<br />
la única API disponible en Python 2.6. En 2.7 pasó a estar considerada obsoleta, y en Python 3.2<br />
no existe, y la nueva <tt class="docutils literal">PyCapsule</tt> debe ser usada. Esto supone un periodo de tránsito entre el<br />
lanzamiento de 2.7 (julio del 2010) al lanzamiento de 3.2 (febrero del 2011) de siete meses; mucho<br />
menor al mínimo de doce meses exigido, y hace más difícil dar soporte a un rango razonable de<br />
versiones de Python.<br />
<br />
Para alguien migrando de 3.0 a 3.1 y después a 3.2, el tránsito es correcto. Python 3.1 fue<br />
lanzado en marzo del 2010 con la marca de obsolescencia, por tanto, en la serie 3.x hay un periodo<br />
de casi 12 meses. Sin embargo, esto no es lo habitual: migran de 2.7 directamente a la última<br />
versión de 3.x; en nuestro caso, 3.2, apareciendo este problema. Nunca fue la intención del equipo<br />
de desarrollo, pero PEP 5 no se escribió para desarrollos de dos versiones en paralelo.<br />
<br />
</div><br />
<div class="section" id="entonces-que-hacemos"><br />
<h4>Entonces, ¿qué hacemos?</h4><br />
Dado que el problema con la API <tt class="docutils literal">PyCObject</tt>/<tt class="docutils literal">PyCapsule</tt> está bien definido, no es imposible<br />
de evitar, pero al menos una persona de python-dev ha tenido algunos problemas con ello.<br />
En resumen, esto no debería haber ocurrido.<br />
<br />
Para el caso específico de <tt class="docutils literal">PyCObject</tt>/<tt class="docutils literal">PyCapsule</tt>, el problema ya existía y no había mucho<br />
que se pudiera hacer. Reincorporar <tt class="docutils literal">PyCObject</tt> no era una opción, dado que sólo añadiría nuevas<br />
incompatibilidades. Sin embargo, la visión general fue que era posible, aunque tedioso, escribir<br />
código que se adaptara a cualquier API disponible. De hecho, en Python 3.1, la API <tt class="docutils literal">PyCObject</tt><br />
fue escrita como un wrapper de la <tt class="docutils literal">PyCapsule</tt>. Había una sugerencia de que, en caso de ser necesitada,<br />
el código de la implementación en 3.1 podría ser extraído y ser usado como código para terceros.<br />
Adicionalmente, se acordó que se escribiría un PEP "retroactivo" cubriendo el cambio, para describir<br />
las razones tras el cambio y documentar los recursos que ayudarían a los programadores a migrar.<br />
<br />
El equipo de Python ahora está al tanto de los problemas y trabajará para evitar que vuelvan a ocurrir.<br />
Guido publicó <a class="reference external" href="http://mail.python.org/pipermail/python-dev/2011-March/109450.html">una reseña</a><br />
de la situación y sugirió que Python 3 debería ser conservativo dejando características obsoletas<br />
por el momento. Como mínimo, las API consideradas obsoletas se conservarán más tiempo antes de ser<br />
eliminadas, para dar a los programadores migrando desde 2.7 un camino más fácil.<br />
<br />
Más indirectamente, el hilo mostró el problema de cómo comunicar de forma más efectiva los cambios<br />
en Python a una audiencia mayor, de forma más oportuna; una de las razones de ser de este blog.<br />
<br />
</div><br />
<div class="section" id="que-significa-todo-esto"><br />
<h4>¿Qué significa todo esto?</h4><br />
En primer lugar, significa que los desarrolladores de Python no lo hacen todo bien. Nadie<br />
quiere hacer la vida de los programadores más difícil, simplemente no fue algo que se viera a tiempo.<br />
<br />
En segundo lugar, arreglar el problema puede hacer aún más daño, así que <tt class="docutils literal">PyCObject</tt> no se<br />
reincorporará. Aunque eso ayudaría a los programadores afectados por el cambio, en global haría los problemas<br />
de compatibilidad más complejos. Mientras tanto, tendremos que sobreponernos al problema y seguir adelante.<br />
La lección está aprendida, y no volveremos a cometer el mismo error de nuevo.<br />
<br />
Una hecho positivo puesto de manifiesto es que el equipo de Python escucha lo que sus usarios tienen que decirles.<br />
La compatibilidad es muy importante, y se pone todo el esfuerzo en hacer la transición a nuevas versiones<br />
tan indolora como sea posible. En particular, los desarrolladores de bibliotecas deberían ser<br />
capaces de soportar varias versiones de Python con un nivel adecuado de esfuerzo.<br />
<br />
Finalmente, los desarrolladores no han abandonado 2.7. No se implementarán nuevas características<br />
y no existirá 2.8, pero la visión de los usuarios de 2.7 todavía es importante. Estar seguros de<br />
que los usuarios pueden migrar a 3.x cuando estén listos es de vital importancia para la comunidad de Python.<br />
<br />
</div><br />
</div>Davidmhhttp://www.blogger.com/profile/14913018830568213369noreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-24613807855777871532011-03-24T14:37:00.000+00:002011-05-25T14:33:00.535+01:00Acerca de muestreos, módulo futures y ejecución en paralelo<p>
Artículo original: <a class="reference external" href="http://blog.python.org/2011/03/of-polling-futures-and-parallel.html">Of polling, futures and parallel execution</a></p>
<p>
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.</p>
<p>
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 <a class="reference external" href="http://www.lesswatts.org/projects/applications-power-management/avoid-pulling.php">está preocupada por esto</a>.</p>
<p>
Python 3.2 viene con un nuevo módulo estándar para lanzar tareas
concurrentes y esperar que terminen: el <a class="reference external" href="http://docs.python.org/dev/library/concurrent.futures.html">módulo concurrent.futures</a>. 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
<a class="reference external" href="http://docs.python.org/dev/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor">ThreadPoolExecutor (basada en hilos)</a>
es diferente que la implementación de <a class="reference external" href="http://docs.python.org/dev/library/concurrent.futures.html#concurrent.futures.ProcessPoolExecutor">ProcessPoolExecutor (basada en
procesos)</a>. 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.</p>
<p>
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.</p>
<p>
Así que se me ocurrió una <a class="reference external" href="http://bugs.python.org/issue11635">solución simple</a>: 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.</p>
<p>
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,
<a class="reference external" href="http://docs.python.org/dev/library/multiprocessing.html#multiprocessing.Queue.get">multiprocessing.Queue.get()</a>
con un tiempo de espera no nulo y finito usaba ... muestreo (por lo
cual abrí el <a class="reference external" href="http://bugs.python.org/issue11668">asunto 11668</a>).
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.</p>
<p>
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.</p>
<p>
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 <a class="reference external" href="http://bugs.python.org/issue7316">asunto 7316</a>.</p>skribihttp://www.blogger.com/profile/15865909805101185858noreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-14969269886307926252011-03-24T08:14:00.000+00:002011-05-25T14:20:35.803+01:00Informe de la Cumbre Language Summit de 2011<div class="document" id="informe-de-la-cumbre-language-summit-de-2011"><br />
<br />
La Language Summit de este año tuvo lugar el jueves 10 de marzo en Atlanta, el<br />
día anterior al comienzo de las conferencias de PyCon. Asistieron representantes<br />
de las implementaciones <a class="reference external" href="http://www.python.org/">CPython</a>, <a class="reference external" href="http://www.pypy.org/">PyPy</a>, <a class="reference external" href="http://www.jython.org/">Jython</a>,<br />
<a class="reference external" href="http://www.ironpython.net/">IronPython</a>, y <a class="reference external" href="http://www.parrot.org/">Parrot</a>; desarrolladores de los paquetes para <a class="reference external" href="http://www.fedoraproject.org/">Fedora</a>,<br />
<a class="reference external" href="http://www.ubuntu.com/">Ubuntu</a>, y <a class="reference external" href="http://www.debian.org/">Debian</a>; desarrolladores del proyecto <a class="reference external" href="http://www.twistedmatrix.com/">Twisted</a> , y muchos otros.<br />
<br />
<div class="section" id="blog-de-desarrollo"><br />
<h4>Blog de desarrollo</h4><br />
Uno de los primeros asuntos tratados fue este mismo blog, iniciado<br />
por el Responsable de Comunicaciones de la PSF, Doug Hellmann.<br />
La lista de correo de python-dev tiene mucho tráfico,<br />
y a menudo muy intenso, por lo que nace este blog. Pretende ser una forma<br />
más sencilla para los usuarios de seguir las novedades del desarrollo.<br />
Pensamos cubrir los PEP, todas las decisiones importantes, nuevas<br />
características y bugs críticos; y se incluirá una cobertura informal de qué<br />
está pasando en el proceso de desarrollo.<br />
<br />
La publicación en el blog está abierta a todas las implementaciones de Python.<br />
Por ejemplo, aunque PyPy ya tiene <a class="reference external" href="http://morepypy.blogspot.com/">su propio blog activo</a>,<br />
estaremos encantados de que publiquen aquí también sus novedades. Una discusión paralela<br />
conduce a implementaciones alternativas, también mencionadas en la<br />
<a class="reference external" href="http://python.org/download">página de descargas de python.org</a>. Las nuevas versiones<br />
liberadas también serán recogidas como nuevos elementos en la página principal de<br />
<a class="reference external" href="http://www.python.org/">python.org</a><br />
<br />
</div><br />
<div class="section" id="advertencias-de-compatibilidad"><br />
<h4>Advertencias de compatibilidad</h4><br />
Con 3.2 introducimos ResourceWarning para que los usuarios pudieran<br />
encontrar áreas de código dependientes del recuento de referencias de CPython. La<br />
advertencia no sólo ayuda a los usuarios a escribir un mejor código, sino que<br />
además les permite escribir código más portable entre diferentes máquinas virtuales.<br />
Para mayor compatibilidad entre implementaciones, se sugirió un nuevo tipo de aviso: CompatibilityWarning<br />
<br />
La idea surgió gracias a un bug en CPython recientemente archivado, encontrado por<br />
los desarrolladores de PyPy (<a class="reference external" href="http://bugs.python.org/issue11455">Issue #11455</a> )<br />
Se explica una situación donde CPython permite al usuario crear un tipo con claves<br />
no de cadena en su <tt class="docutils literal">__dict</tt>, que al menos PyPy y Jython no soportan. Idealmente,<br />
los usuarios podrían activar una advertencia para detectar estos casos, tal y como<br />
hacen con ResourceWarning.<br />
<br />
</div><br />
<div class="section" id="biblioteca-estandar-independiente"><br />
<h4>Biblioteca Estándar independiente</h4><br />
Ahora que la transición del código de Cpython de Subversion a Mercurial ha sido<br />
completada, ha resurgido la idea de separar la biblioteca estándar a su propio<br />
repositorio. Los desarrolladores de las implementaciones alternativas están muy<br />
interesados, ya que esto simplificaría enromemente su proceso de desarrollo.<br />
A día de hoy, toman una instantánea de CPython y le aplican cualquier<br />
implementación específica, reemplazan algunas extensiones en C con versiones<br />
de Python puro, etc.<br />
<br />
La conversión tendrá que ser definida en un próximo PEP. Uno de los<br />
puntos de la discusión es cómo se implementará el control de versiones.<br />
Dado que la biblioteca vivirá fuera de cualquiera de las implementaciones,<br />
es probable que sea controlada por sí misma, y las pruebas necesitarán considerar<br />
también la versión.<br />
<br />
Otra asunto a tratar en la separación de la biblioteca es la implementación en<br />
Python puro o sus equivalentes en C. Maciej Fijalkowski, del proyecto PyPy,<br />
mencionó que con el tiempo, algunos módulos han tenido pequeñas diferencias<br />
entre sus versiones en C y Python. Mientras la discusión sobre esta separación continúa,<br />
el equipo ha sugerido un enfoque más estricto a los cambios en dichos módulos<br />
para no penalizar el uso de uno u otro. Se prefirió, además, la implementación en Python,<br />
reservando las versiones en C sólo para los casos en los que se obtenga una mejora en el rendimiento.<br />
<br />
</div><br />
<div class="section" id="pagina-de-logros-de-rendimiento"><br />
<h4>Página de logros de rendimiento</h4><br />
El Speed Center de PyPy ha hecho un gran trabajo mostrando los resultados del<br />
rendimiento de PyPy, y sugirió cierta discusión sobre si alojar un sitio similar<br />
en python.org, posiblemente performance.python.org, para todas las máquinas virtuales<br />
que tomen parte. Además de los logros de rendimiento, se deberán considerar cosas como<br />
uso de memoria, tests pasados y compatibilidad del lenguage. Actualmente se compara<br />
PyPy y CPython, por lo que se necesitará cierto trabajo para adaptar la infraestructura<br />
para trabajar con otras implementaciones.<br />
<br />
El nuevo Speed Center podría vivir en el <a class="reference external" href="http://osuosl.org/">Laboratorio de Código Abierto<br />
en la Oregon State University</a> (Allison Randal pertenece a su junta<br />
directiva). Jesse Noller mencionó el esfuerzo que supone obtener máquinas de alto rendimiento<br />
para instalar. ¡Las donaciones son bienvenidas!<br />
<br />
Si tú o tu organización estáis interesados en donar para esta causa, u otras, por favor<br />
contactad con la <a class="reference external" href="http://www.python.org/psf/about">Python Software Foundation</a>, y visitad<br />
nuestra <a class="reference external" href="http://www.python.org/psf/donations">página de donaciones</a>.<br />
<br />
</div><br />
<div class="section" id="levantamiento-de-la-moratoria"><br />
<h4>Levantamiento de la moratoria</h4><br />
Con el comienzo del desarrollo de CPython 3.3, la moratoria en los cambios del<br />
lenguaje se ha levantado. Aunque no hay límites definidos, se espera que los cambios<br />
sean conservativos. Al intentar reducir el ritmo de cambio, permitimos que las<br />
implementaciones alternativas se pongan al día. Si bien ninguna logró llegar a<br />
la familia 3.x, gracias a la moratoria, PyPy y IronPython alcanzaron recientemente<br />
la compatibilidad con 2.7, e IronPython ha comenzado su andadura hacia 3.x.<br />
<br />
En cuanto a los cambios que se esperan en 3.3, esperamos que el<br />
<a class="reference external" href="http://www.python.org/dev/peps/pep-0380/">PEP 380</a> sea aceptado. Este PEP introduce<br />
una nueva sintaxis para <tt class="docutils literal">yield from <expr></tt>, permitiendo a un generador devolver mediante un <tt class="docutils literal">yield</tt><br />
otro generador. Aparte de esto, no se esperan más cambios en el futuro cercano.<br />
<br />
</div><br />
<div class="section" id="atributos-de-las-excepciones"><br />
<h4>Atributos de las excepciones</h4><br />
El siguiente tema fue una rápida discusión sobre las excepciones. Éstas deberían proporcionar<br />
mejores atributos, en lugar de forzar a los usuarios a confiar en mensajes en strings. Por ejemplo,<br />
en un ImportError, sería útil tener fácil acceso al import que ha fallado, en lugar de tener que analizarlo<br />
para identificarlo.<br />
<br />
La implementación se basará probablemente en un argumento palabra clave cuando se inicialize<br />
el objeto excepción. Actualmente existe un parche para el caso del<br />
<a class="reference external" href="http://bugs.python.org/issue8754">ImportError</a>.<br />
<br />
</div><br />
<div class="section" id="acuerdos-de-contribucion"><br />
<h4>Acuerdos de contribución</h4><br />
Los acuerdos de contribución fueron también mencionados, y algunos acuerdos electrónicos están en marcha.<br />
El <a class="reference external" href="http://code.google.com/legal/individual-cla-v1.0.html">acuerdo de contribución individual</a><br />
de Google fue una de las múltiples inspiraciones sobre el funcionamiento del nuevo sistema.<br />
El asunto ha sido extensamente discutido, y mucha gente está deseando una resolución en este área.<br />
Adicionalmente, se está investigando para asegurar que cualquier un acuerdo electrónico sea válido en<br />
jurisdicciones fuera de EE.UU.<br />
<br />
</div><br />
<div class="section" id="google-summer-of-code"><br />
<h4>Google Summer of Code</h4><br />
Martin von Lšwis dedicó un minuto para introducir otro año del Google Summer of Code, bajo el paraguas<br />
de la PSF. Se anima a los desarrolladores a actuar no sólo como maestros, sino también proponiendo<br />
proyectos en los que trabajar a los estudiantes (y recordar que sugerir un proyecto no implica que lo<br />
vayas a supervisar tú). Si estás interesado en ayudar en cualquier forma, visita la<br />
<a class="reference external" href="http://pyfound.blogspot.com/2011/03/google-summer-of-code-call-for-projects.html">convocatoria para proyectos y mentores</a>.<br />
de la PSF.<br />
<br />
</div><br />
<div class="section" id="distutils"><br />
<h4>Distutils</h4><br />
Le llegó el turno a <a class="reference external" href="https://bitbucket.org/tarek/distutils2/wiki/Home">Distutils2</a>, y Tarek ZiadŽ mencionó que su objetivo a corto plazo es terminar<br />
la migración a Python 3 y prepararlo para la consiguiente fusión de nuevo en la biblioteca estándar de Python.<br />
Adicionalmente, con la nueva fusión viene un nuevo nombre: <tt class="docutils literal">packaging</tt>. El equipo de packaging también planea<br />
proeveer un paquete independiente, todavía llamado Distutils2, soportando desde Python 2.4 hasta 3.2.<br />
<br />
El resultado del sprint de packaging, que fue uno de los mayores grupos de la PyCon, fue muy bueno. Sus resultados están<br />
en <a class="reference external" href="https://bitbucket.org/tarek/cpython">Bitbucket</a>, esperando su fusión con la biblioteca estándar.<br />
<br />
</div><br />
<div class="section" id="el-futuro-de-las-maquinas-virtuales-alternativas"><br />
<h4>El futuro de las máquinas virtuales alternativas</h4><br />
IronPython comentó sus planes de futuro, y el lanzamiento de la 3.x está próximo.<br />
Anunciaron el de su versión 2.7.0 en la PyCon, su primera versión basada<br />
en la comunidad desde que el proyecto fue cedido por Microsoft, y comenzarán el trabajo<br />
hacia la 3.x en los siguientes meses.<br />
<br />
Jython publicó recientemente la versión 2.5.2, y ha comenzado a planear la 2.6.<br />
Algunos han sugerido que salten a la 2.7, ya que las diferencias entre ambas no son<br />
grandes; pero el salto podría retrasar la primera liberación. La frase "libera pronto, libera a menudo"<br />
fue citada en la charla. Podrían ser capaces de dar el salto de la 2.6 a 3.x y considerar<br />
las diferencias entre 2.6 y 2.7 después.<br />
<br />
</div><br />
<div class="section" id="financiacion-del-desarrollo"><br />
<h4>Financiación del desarrollo</h4><br />
Aparte de los planes para la 3.x, está el asunto de la financiación del desarrollo y cómo<br />
facilitar el que alguna de las implementaciones alternativas alcance la serie 3.x.<br />
En cualquier caso, se debe hacer una propuesta a la PSF antes de que nada pueda ser<br />
discutido. Aquellos interesados en recibir becas por su trabajo, deberían contactar la Junta de la PSF.<br />
<br />
</div><br />
<div class="section" id="meta-de-python"><br />
<h4>Meta de Python</h4><br />
Jim Fulton comenzó una discusión sobre lo que él llamó la "meta" de Python. En su<br />
experiencia desplegando aplicaciones de Python, se ha encontrado con que el sistema<br />
es impredecible y dificil de manejar. Con expertos en empaquetado de Fedora y<br />
Ubuntu/Debian a mano, fuimos capaces de echar una mirada crítica a por qué las cosas<br />
son como son.<br />
<br />
En Fedora, la instalación básica de Python está basada en el Live CD, por lo que<br />
es una versión mínima con pocas dependencias, los mínimos exigibles para que el sistema<br />
pueda correr. Otras diferencias que se ven son la eliminación de<br />
módulos de la biblioteca estándar, como distutils, o que la distribución incluye bibliotecas<br />
desfasadas.<br />
<br />
No parece que a día de hoy haya una solución clara, pero las partes implicadas<br />
continuarán trabajando en el problema.<br />
<br />
</div><br />
<div class="section" id="caracteristicas-de-la-3-3"><br />
<h4>Características de la 3.3</h4><br />
Srgieron algunas ideas para la 3.3, incluyendo dos PEP.<br />
El<br />
<a class="reference external" href="http://www.python.org/dev/peps/pep-0382">PEP 382</a>, acerca de los espacios<br />
de nombres en paquetes debería aparecer en algún punto del ciclo. También<br />
fue mencionado durante la discusión de la fusión de distutils.<br />
<br />
El <a class="reference external" href="http://www.python.org/dev/peps/pep-0393">PEP 393</a>, que define una representación<br />
flexible de las strings, fue también discutido, y despertó el interés de algunos estudiantes<br />
como proyecto GSoC. Junto con las implementaciones, se necesitará dedicar cierto esfuerzo<br />
para caracterizar el rendimiento y uso de memoria para ver si pueden ser aceptados.<br />
<br />
</div><br />
<div class="section" id="unladen-swallow"><br />
<h4>Unladen Swallow</h4><br />
Unladen Swallow (<i>golondrina sin carga</i>) está a día de hoy en un estado de "reposo"<br />
y no se incluirá en CPython 3.3. Para progresar, necesitaremos la ayuda de<br />
más desarrolladores, ya que los expertos actuales son insuficientes para realizar<br />
el trabajo. Durante la discusión, se comentó de nuevo que si la financiación es lo que<br />
empujaría Undaden Swallow al siguiente nivel, los interesados deberían contactar con la PSF.<br />
<br />
Aunque Unladen Swallow esté en estado de reposo y su futuro sea incierto, el proyecto<br />
ha proporcionado múltiples beneficios a Python y a la comunidad de código abierto en general.<br />
Por ejemplo, el conjunto de herramientas de pruebas de rendimiento usado por Unladen Swallow es muy útil para<br />
probar implementaciones alternativas. Además, desarrolladores de Unladen Swallow han contribuído<br />
a LLVM y Clang.<br />
<br />
Otras dos ideas de rendimiento fueron discutidas brevemente, incluyendo la propuesta de<br />
Dave Malcom de incluir el código de funciones en el propio cuerpo (<i>inlining</i>). Martin von Lšwis<br />
comentó que está trabajando en un módulo de compilación al vuelo, aunque los desarrolladores de PyPy<br />
expresaron su escepticismo acerca de la efectividad de este tipo de sistemas.<br />
<br />
</div><br />
<div class="section" id="pavimentando-el-camino-a-los-frameworks-asincronos"><br />
<h4>Pavimentando el camino a los frameworks asíncronos</h4><br />
Al final del día hubo una discusión acerca del nivel de integración de Twisted<br />
en la biblioteca estándar. La idea principal es que existe una alternativa a asyncore<br />
que permite una una transición más fácil a Twisted o otros frameworks de programación<br />
asíncronos.<br />
<br />
El proceso se llevará a cabo en un PEP, que algunos han sugerido servirá para un propósito<br />
similar a la WSGI, pero para bucles de eventos asíncronos. Junto con los autores del PEP,<br />
el proyecto Twisted y otros necesitarán esforzarse en asegurarse de que todo el mundo está<br />
en el mismo lado.<br />
<br />
</div><br />
<div class="section" id="mas-informacion"><br />
<h4>Más información</h4><br />
Para más información, lee las notas de<br />
<a class="reference external" href="http://www.boredomandlaziness.org/2011/03/python-language-summit-rough-notes.html">Nick Coghlan</a><br />
(desarrollador de CPython) y<br />
<a class="reference external" href="http://www.boredomandlaziness.org/2011/03/python-language-summit-highlights.html">lo más destacado</a> (en inglés).<br />
<br />
</div><br />
</div>Davidmhhttp://www.blogger.com/profile/14913018830568213369noreply@blogger.com0tag:blogger.com,1999:blog-4579165749808948819.post-4589053552349334732011-03-23T23:35:00.000+00:002011-05-25T14:19:53.226+01:00¡Bienvenido a Python Insider!<div class="document" id="bienvenido-a-python-insider"><br />
<br />
<a class="reference external" href="http://blog.python.org/">Python Insider</a> es la traducción del blog oficial del equipo de<br />
desarrollo del core de Python. Es un resumen de los asuntos tratados en la<br />
lista de correo de los desarrolladores, con especial hincapié en<br />
los cambios que sobrevendrán a Python. Haremos un resumen de la actividad<br />
de Python-Dev, como la reciente migración a Mercurial, los últimos<br />
Python Enhancement Proposals (PEP) aprobados, cambios en la API<br />
y otros asuntos relevantes en el desarrollo del núcleo de Python.<br />
<br />
El blog, más que un substituto, será un complemento de la lista de<br />
correo <a class="reference external" href="http://mail.python.org/mailman/listinfo/python-dev">python-dev</a> y de los blogs personales de los desarrolladores (véase<br />
los enlaces en la barra lateral). Servirá de canal para hablar públicamente<br />
de los proyectos una vez completados, o cuando llegue el momento en el que necesiten<br />
más voluntarios. Agradecemos la discusión en el blog, pero esperamos que aquellos<br />
interesados se una a la lista de correo y puedan seguir las discusiones directamente.<br />
<br />
El idioma común a todos los desarrolladores es el inglés, así que siempre que sea posible,<br />
usa los canales originales para que tu opinión pueda llegar a donde debe.<br />
<br />
Puedes pensar en este blog como una ventana a la evolución de Python.<br />
<br />
<div class="section" id="como-suscribirte"><br />
<h4>Cómo suscribirte</h4><br />
Hay varias formas de seguir <a class="reference external" href="http://blog.python.org/">Python Insider</a>:<br />
<br />
<ul class="simple"><li><a class="reference external" href="http://planet.python.org/">Planet Python</a></li>
<li><a class="reference external" href="http://blog.python.org/">En la web</a></li>
<li><a class="reference external" href="http://feeds.feedburner.com/PythonInsider">Feed Atom/RSS</a></li>
<li><a class="reference external" href="http://twitter.com/PythonInsider">@PythonInsider</a> en Twitter (en inglés)</li>
<li><a class="reference external" href="http://feedburner.google.com/fb/a/mailverify?uri=PythonInsider&loc=en_US">Correo electrónico</a></li>
</ul><br />
</div><br />
<div class="section" id="se-busca-ayuda"><br />
<h4>Se busca ayuda</h4><br />
Aunque disponemos de un equipo dedicado a escribir entradas para el blog,<br />
estamos buscando a alguien con habilidades en diseño web para trabajar en la<br />
plantilla de Blogger. También estamos buscando gente dispuesta a traducir a otros idiomas.<br />
Si puedes ayudar mejorando el aspecto del blog o traduciendo, por favor<br />
contacta con Doug Hellmann (doug dot hellmann en gmail).<br />
<br />
</div><br />
</div>Davidmhhttp://www.blogger.com/profile/14913018830568213369noreply@blogger.com0