# Novedades de Python 2.5

Autor

  A.M. Kuchling

This article explains the new features in Python 2.5. The final release of Python 2.5 is scheduled for August 2006; PEP 356 describes the planned release schedule. Python 2.5 was released on September 19, 2006.

The changes in Python 2.5 are an interesting mix of language and library improvements. The library enhancements will be more important to Python’s user community, I think, because several widely useful packages were added. New modules include ElementTree for XML processing (`xml.etree`), the SQLite database module (`sqlite`), and the `ctypes` module for calling C functions.

Los cambios en el lenguaje son de mediana importancia. Se han añadido algunas características nuevas y agradables, pero la mayoría de ellas no son características que vaya a utilizar todos los días. Las expresiones condicionales fueron finalmente añadidas al lenguaje usando una nueva sintaxis; ver sección PEP 308: Expresiones condicionales. La nueva sentencia “`with`” facilitará la escritura de código de limpieza (sección PEP 343: La declaración «con). Ahora se pueden pasar valores a los generadores (sección PEP 342: Nuevas funciones del generador). Las importaciones son ahora visibles como absolutas o relativas (sección PEP 328: Importaciones absolutas y relativas). Se han mejorado algunos casos de manejo de excepciones (sección PEP 341: Try/except/finally unificados). Todas estas mejoras merecen la pena, pero son mejoras de una u otra característica específica del lenguaje; ninguna de ellas es una modificación amplia de la semántica de Python.

Además de las adiciones al lenguaje y a la biblioteca, se han realizado otras mejoras y correcciones de errores en todo el árbol de código fuente. Una búsqueda en los registros de cambios del SVN revela que se aplicaron 353 parches y se corrigieron 458 errores entre Python 2.4 y 2.5. (Es probable que ambas cifras estén subestimadas)

Este artículo no pretende ser una especificación completa de las nuevas características; en su lugar, los cambios se introducen brevemente utilizando ejemplos útiles. Para obtener todos los detalles, siempre debes consultar la documentación de Python 2.5 en https://docs.python.org. Si quieres entender la implementación completa y los fundamentos del diseño, consulta el PEP de una nueva característica en particular.

Son bienvenidos los comentarios, las sugerencias y los informes de errores para este documento; por favor, envíelos por correo electrónico al autor o abra un error en el rastreador de errores de Python.

## PEP 308: Expresiones condicionales

Durante mucho tiempo, la gente ha solicitado una forma de escribir expresiones condicionales, que son expresiones que devuelven el valor A o el valor B dependiendo de si un valor booleano es verdadero o falso. Una expresión condicional le permite escribir una única sentencia de asignación que tiene el mismo efecto que la siguiente:

    if condition:
        x = true_value
    else:
        x = false_value

Ha habido interminables y tediosas discusiones sobre la sintaxis tanto en python-dev como en comp.lang.python. Incluso se llevó a cabo una votación en la que se descubrió que la mayoría de los votantes querían expresiones condicionales de alguna forma, pero no había ninguna sintaxis que fuera preferida por una clara mayoría. Los candidatos incluían `cond ? true_v : false_v`, `if cond then true_v else false_v`, y otras 16 variaciones.

Guido van Rossum eligió finalmente una sintaxis sorprendente:

    x = true_value if condition else false_value

La evaluación sigue siendo perezosa como en las expresiones booleanas existentes, por lo que el orden de evaluación salta un poco. La expresión condición del medio se evalúa primero, y la expresión valor_verdadero se evalúa sólo si la condición es verdadera. Del mismo modo, la expresión valor_falso sólo se evalúa cuando la condición es falsa.

Esta sintaxis puede parecer extraña y retrógrada; ¿por qué la condición va en el medio de la expresión, y no en la parte delantera como en `c ? x : y` de C? La decisión se comprobó aplicando la nueva sintaxis a los módulos de la biblioteca estándar y viendo cómo se leía el código resultante. En muchos casos en los que se utiliza una expresión condicional, un valor parece ser el «caso común» y otro valor es un «caso excepcional», utilizado sólo en las raras ocasiones en las que no se cumple la condición. La sintaxis condicional hace que este patrón sea un poco más obvio:

    contents = ((doc + '\n') if doc else '')

Leo la afirmación anterior en el sentido de que «aquí se asigna a contents un valor de `doc+'\n'`; a veces doc está vacío, en cuyo caso especial se devuelve una cadena vacía» Dudo que use expresiones condicionales muy a menudo donde no hay un caso común y no común claro.

Hubo alguna discusión sobre si el lenguaje debería requerir rodear las expresiones condicionales con paréntesis. Se tomó la decisión de no requerir paréntesis en la gramática del lenguaje Python, pero como una cuestión de estilo creo que siempre deberías usarlos. Considere estas dos declaraciones:

    # First version -- no parens
    level = 1 if logging else 0

    # Second version -- with parens
    level = (1 if logging else 0)

En la primera versión, creo que el ojo de un lector podría agrupar la sentencia en “nivel = 1”, “si registro”, “si no 0”, y pensar que la condición decide si se realiza la asignación a nivel. La segunda versión se lee mejor, en mi opinión, porque deja claro que la asignación se realiza siempre y que se está eligiendo entre dos valores.

Otra razón para incluir los paréntesis: algunas combinaciones extrañas de comprensiones de listas y lambdas podrían parecer expresiones condicionales incorrectas. Véase PEP 308 para algunos ejemplos. Si pone paréntesis alrededor de sus expresiones condicionales, no se encontrará con este caso.

Ver también

PEP 308 - Expresiones condicionales

  PEP escrito por Guido van Rossum y Raymond D. Hettinger; implementado por Thomas Wouters.

## PEP 309: Aplicación parcial de funciones

El módulo `functools` está destinado a contener herramientas para la programación de estilo funcional.

Una herramienta útil de este módulo es la función `partial()`. Para los programas escritos en un estilo funcional, a veces querrá construir variantes de funciones existentes que tengan algunos de los parámetros rellenados. Considere una función Python `f(a, b, c)`; podría crear una nueva función `g(b, c)` que fuera equivalente a `f(1, b, c)`. Esto se llama «aplicación parcial de funciones».

`parcial()` toma los argumentos `(function, arg1, arg2, ... kwarg1=valor1, kwarg2=valor2)`. El objeto resultante es invocable, por lo que puedes llamarlo para invocar la función con los argumentos rellenados.

He aquí un pequeño pero realista ejemplo:

    import functools

    def log (message, subsystem):
        "Write the contents of 'message' to the specified subsystem."
        print '%s: %s' % (subsystem, message)
        ...

    server_log = functools.partial(log, subsystem='server')
    server_log('Unable to open socket')

Aquí hay otro ejemplo, de un programa que utiliza PyGTK. Aquí se está construyendo dinámicamente un menú emergente sensible al contexto. El callback proporcionado para la opción de menú es una versión parcialmente aplicada del método `open_item()`, donde se ha proporcionado el primer argumento

    ...
    class Application:
        def open_item(self, path):
           ...
        def init (self):
            open_func = functools.partial(self.open_item, item_path)
            popup_menu.append( ("Open", open_func, 1) )

Otra función del módulo `functools` es la función `update_wrapper(wrapper, wrapped)` que le ayuda a escribir decoradores con un buen comportamiento. `update_wrapper()` copia el nombre, el módulo y el atributo docstring a una función wrapper para que las trazas dentro de la función envuelta sean más fáciles de entender. Por ejemplo, puedes escribir:

    def my_decorator(f):
        def wrapper(*args, **kwds):
            print 'Calling decorated function'
            return f(*args, **kwds)
        functools.update_wrapper(wrapper, f)
        return wrapper

`wraps()` es un decorador que se puede utilizar dentro de sus propios decoradores para copiar la información de la función envuelta. Una versión alternativa del ejemplo anterior sería:

    def my_decorator(f):
        @functools.wraps(f)
        def wrapper(*args, **kwds):
            print 'Calling decorated function'
            return f(*args, **kwds)
        return wrapper

Ver también

PEP 309 - Aplicación parcial de funciones

  PEP propuesto y escrito por Peter Harris; implementado por Hye-Shik Chang y Nick Coghlan, con adaptaciones de Raymond Hettinger.

## PEP 314: Metadatos para paquetes de software Python v1.1

Se ha añadido a Distutils un sencillo soporte de dependencias. La función `setup()` ahora tiene parámetros de palabras clave `requires`, `provides` y `obsoletes`. Cuando se construye una distribución de origen utilizando el comando `sdist`, la información de las dependencias se registrará en el archivo `PKG-INFO`.

Otro nuevo parámetro de palabra clave es `download_url`, que debe establecerse como una URL para el código fuente del paquete. Esto significa que ahora es posible buscar una entrada en el índice de paquetes, determinar las dependencias de un paquete y descargar los paquetes necesarios.

    VERSION = '1.0'
    setup(name='PyPackage',
          version=VERSION,
          requires=['numarray', 'zlib (>=1.1.4)'],
          obsoletes=['OldPackage']
          download_url=('http://www.example.com/pypackage/dist/pkg-%s.tar.gz'
                        % VERSION),
         )

Otra nueva mejora en el índice de paquetes de Python en https://pypi.org es el almacenamiento de archivos fuente y binarios de un paquete. El nuevo comando upload de Distutils subirá un paquete al repositorio.

Antes de poder subir un paquete, debes ser capaz de construir una distribución usando el comando sdist de Distutils. Una vez que funcione, puedes ejecutar `python setup.py upload` para añadir tu paquete al archivo PyPI. Opcionalmente puedes firmar el paquete con GPG suministrando las opciones `--sign` y `--identity`.

La carga de paquetes fue implementada por Martin von Löwis y Richard Jones.

Ver también

PEP 314 - Metadatos para paquetes de software Python v1.1

  PEP propuesto y redactado por A.M. Kuchling, Richard Jones y Fred Drake; aplicado por Richard Jones y Fred Drake.

## PEP 328: Importaciones absolutas y relativas

La parte más sencilla de PEP 328 se implementó en Python 2.4: los paréntesis podían utilizarse ahora para encerrar los nombres importados de un módulo utilizando la sentencia `from ... import ...`, facilitando la importación de muchos nombres diferentes.

La parte más complicada se ha implementado en Python 2.5: la importación de un módulo puede especificarse para utilizar importaciones absolutas o relativas al paquete. El plan es hacer que las importaciones absolutas sean el valor por defecto en futuras versiones de Python.

Digamos que tienes un directorio de paquetes como este:

    pkg/
    pkg/__init__.py
    pkg/main.py
    pkg/string.py

Esto define un paquete llamado `pkg` que contiene los submódulos `pkg.main` y `pkg.string`.

Considera el código del módulo `main.py`. ¿Qué ocurre si ejecuta la sentencia `importar cadena`? En Python 2.4 y anteriores, primero buscará en el directorio del paquete para realizar una importación relativa, encuentra `pkg/string.py`, importa el contenido de ese archivo como el módulo `pkg.string`, y ese módulo se vincula al nombre `string` en el espacio de nombres del módulo `pkg.main`.

Eso está bien si `pkg.string` era lo que querías. ¿Pero qué pasa si quieres el módulo estándar de Python `string`? No hay una forma limpia de ignorar `pkg.string` y buscar el módulo estándar; generalmente tienes que mirar el contenido de `sys.modules`, lo cual es ligeramente sucio. El paquete `py.std` de Holger Krekel proporciona una forma más ordenada de realizar importaciones desde la biblioteca estándar, `import py; py.std.string.join()`, pero ese paquete no está disponible en todas las instalaciones de Python.

La lectura de código que depende de importaciones relativas también es menos clara, porque un lector puede confundirse sobre qué módulo, `cadena` o `cadena.pkg`, se pretende utilizar. Los usuarios de Python aprendieron pronto a no duplicar los nombres de los módulos de la biblioteca estándar en los nombres de los submódulos de sus paquetes, pero no puedes protegerte de que el nombre de tu submódulo se utilice para un nuevo módulo añadido en una futura versión de Python.

En Python 2.5, puedes cambiar el comportamiento de `import` a importaciones absolutas usando una directiva `from __future__ import absolute_import`. Este comportamiento de importación absoluta será el predeterminado en una versión futura (probablemente Python 2.7). Una vez que las importaciones absolutas sean el valor por defecto, `import string` siempre encontrará la versión de la biblioteca estándar. Se sugiere que los usuarios comiencen a usar importaciones absolutas tanto como sea posible, así que es preferible comenzar a escribir `de pkg import string` en su código.

Las importaciones relativas siguen siendo posibles añadiendo un punto inicial al nombre del módulo cuando se utiliza la forma `from ... import`:

    # Import names from pkg.string
    from .string import name1, name2
    # Import pkg.string
    from . import string

Esto importa el módulo `string` relativo al paquete actual, así que en `pkg.main` esto importará nombre1 y nombre2 de `pkg.string`. Los puntos iniciales adicionales realizan la importación relativa empezando por el padre del paquete actual. Por ejemplo, el código en el módulo `A.B.C` puede hacer:

    from . import D                 # Imports A.B.D
    from .. import E                # Imports A.E
    from ..F import G               # Imports A.F.G

Los puntos suspensivos no pueden usarse con la forma `importar nombre de modelo` de la sentencia import, sólo con la forma `de ... import`.

Ver también

PEP 328 - Importaciones: Multilínea y Absoluto/Relativo

  PEP escrito por Aahz; implementado por Thomas Wouters.

https://pylib.readthedocs.io/

  La biblioteca py de Holger Krekel, que contiene el paquete `py.std`.

## PEP 338: Ejecutando Módulos como Scripts

El conmutador `-m` añadido en Python 2.4 para ejecutar un módulo como un script ganó algunas habilidades más. En lugar de estar implementado en código C dentro del intérprete de Python, el interruptor ahora utiliza una implementación en un nuevo módulo, `runpy`.

El módulo `runpy` implementa un mecanismo de importación más sofisticado de forma que ahora es posible ejecutar módulos en un paquete como `pychecker.checker`. El módulo también soporta mecanismos de importación alternativos como el módulo `zipimport`. Esto significa que puede añadir la ruta de un archivo .zip a `sys.path` y luego utilizar el modificador `-m` para ejecutar el código del archivo.

Ver también

PEP 338 - Ejecución de módulos como scripts

  PEP escrito e implementado por Nick Coghlan.

## PEP 341: Try/except/finally unificados

Hasta la versión 2.5 de Python, la sentencia `try` tenía dos variantes. Podías usar un bloque `finally` para asegurarte de que el código se ejecutaba siempre, o uno o más bloques `except` para capturar excepciones específicas. No podías combinar ambos bloques `except` y un bloque `finally`, porque generar el bytecode correcto para la versión combinada era complicado y no estaba claro cuál debía ser la semántica de la sentencia combinada.

Guido van Rossum pasó algún tiempo trabajando con Java, que sí soporta el equivalente de combinar bloques `except` y un bloque `finally`, y esto aclaró lo que debería significar la declaración. En Python 2.5, ahora se puede escribir:

    try:
        block-1 ...
    except Exception1:
        handler-1 ...
    except Exception2:
        handler-2 ...
    else:
        else-block
    finally:
        final-block

Se ejecuta el código del bloque-1. Si el código lanza una excepción, se comprueban los distintos bloques `except`: si la excepción es de clase `Exception1`, se ejecuta handler-1; en caso contrario, si es de clase `Exception2`, se ejecuta handler-2, y así sucesivamente. Si no se produce ninguna excepción, se ejecuta el bloque else.

No importa lo que haya sucedido previamente, el bloque final se ejecuta una vez que el bloque de código se ha completado y se han manejado las excepciones planteadas. Incluso si hay un error en un manejador de excepciones o en el bloque else y se lanza una nueva excepción, el código del bloque final se sigue ejecutando.

Ver también

PEP 341 - Unificar try-except y try-finally

  PEP escrito por Georg Brandl; implementación por Thomas Lee.

## PEP 342: Nuevas funciones del generador

Python 2.5 añade una forma sencilla de pasar valores a un generador. Tal y como se introdujo en Python 2.3, los generadores sólo producen salida; una vez que se invoca el código de un generador para crear un iterador, no hay forma de pasar ninguna información nueva a la función cuando se reanuda su ejecución. A veces, la capacidad de pasar alguna información sería útil. Las soluciones más ingeniosas para esto incluyen hacer que el código del generador mire a una variable global y luego cambie el valor de la variable global, o pasar algún objeto mutable que los llamadores luego modifiquen.

Para refrescar la memoria de los generadores básicos, he aquí un ejemplo sencillo:

    def counter (maximum):
        i = 0
        while i < maximum:
            yield i
            i += 1

Cuando se llama a `contador(10)`, el resultado es un iterador que devuelve los valores de 0 a 9. Al encontrar la sentencia `yield`, el iterador devuelve el valor proporcionado y suspende la ejecución de la función, preservando las variables locales. La ejecución se reanuda en la siguiente llamada al método `next()` del iterador, retomando después de la sentencia `yield`.

En Python 2.3, `yield` era una declaración; no devolvía ningún valor. En 2.5, `yield` es ahora una expresión, que devuelve un valor que se puede asignar a una variable o que se puede operar de otra manera:

    val = (yield i)

Te recomiendo que siempre pongas paréntesis alrededor de una expresión `yield` cuando estés haciendo algo con el valor devuelto, como en el ejemplo anterior. Los paréntesis no siempre son necesarios, pero es más fácil añadirlos siempre en lugar de tener que recordar cuándo son necesarios.

(PEP 342 explica las reglas exactas, que consisten en que una expresión `yield`debe ir siempre entre paréntesis, excepto cuando ocurre en la expresión de nivel superior en el lado derecho de una asignación. Esto significa que puedes escribir `val = yield i` pero tienes que usar paréntesis cuando hay una operación, como en `val = (yield i) + 12`)

Los valores se envían a un generador llamando a su método `send(value)`. El código del generador se reanuda y la expresión `yield` devuelve el valor especificado. Si se llama al método regular `next()`, la expresión `yield` devuelve `None`.

Aquí está el ejemplo anterior, modificado para permitir cambiar el valor del contador interno.

    def counter (maximum):
        i = 0
        while i < maximum:
            val = (yield i)
            # If value provided, change counter
            if val is not None:
                i = val
            else:
                i += 1

Y aquí hay un ejemplo de cambio de contador:

    >>> it = counter(10)
    >>> print it.next()
    0
    >>> print it.next()
    1
    >>> print it.send(8)
    8
    >>> print it.next()
    9
    >>> print it.next()
    Traceback (most recent call last):
      File "t.py", line 15, in ?
        print it.next()
    StopIteration

`yield` normalmente devolverá `None`, por lo que siempre debes comprobar este caso. No utilices su valor en las expresiones sin más, a menos que estés seguro de que el método `send()` será el único utilizado para reanudar tu función generadora.

Además de `send()`, hay otros dos nuevos métodos en los generadores:

- `throw(type, value=None, traceback=None)` se utiliza para lanzar una excepción dentro del generador; la excepción es lanzada por la expresión `yield` donde la ejecución del generador se pausa.

- `close()` lanza una nueva excepción `GeneratorExit` dentro del generador para terminar la iteración. Al recibir esta excepción, el código del generador debe lanzar `GeneratorExit` o `StopIteration`. Capturar la excepción `GeneratorExit` y devolver un valor es ilegal y provocará un `RuntimeError`; si la función lanza alguna otra excepción, esa excepción se propaga a quien la llama. `close()` también será llamado por el recolector de basura de Python cuando el generador sea recolectado.

  Si necesitas ejecutar código de limpieza cuando se produce un `GeneratorExit`, te sugiero que utilices un conjunto `try: ... finally:` en lugar de atrapar `GeneratorExit`.

El efecto acumulativo de estos cambios es que los generadores pasan de ser productores unidireccionales de información a ser tanto productores como consumidores.

Los generadores también se convierten en corutinas, una forma más generalizada de subrutinas. Las subrutinas se introducen en un punto y se salen en otro (la parte superior de la función, y una declaración `return`), pero las coroutines pueden introducirse, salirse y reanudarse en muchos puntos diferentes (las declaraciones `yield`). Tendremos que descubrir patrones para usar coroutines de forma efectiva en Python.

La adición del método `close()` tiene un efecto secundario que no es obvio. `close()` es llamado cuando un generador es recogido por la basura, lo que significa que el código del generador tiene una última oportunidad de ejecutarse antes de que el generador sea destruido. Esta última oportunidad significa que ahora se puede garantizar que las sentencias `intentar...finalmente` en los generadores funcionen; la cláusula `finally` ahora siempre tendrá una oportunidad de ejecutarse. Por lo tanto, se ha eliminado la restricción sintáctica que impedía mezclar sentencias `yield` con un conjunto `try...finally`. Esto parece una trivialidad menor del lenguaje, pero el uso de generadores y `try...finally` es realmente necesario para implementar la sentencia `with` descrita por PEP 343. Veré esta nueva sentencia en la siguiente sección.

Otro efecto aún más esotérico de este cambio: antes, el atributo `gi_frame` de un generador era siempre un objeto frame. Ahora es posible que `gi_frame` sea `None` una vez que el generador se ha agotado.

Ver también

PEP 342 - Coroutines mediante generadores mejorados

  PEP escrito por Guido van Rossum y Phillip J. Eby; implementado por Phillip J. Eby. Incluye ejemplos de algunos usos más sofisticados de los generadores como coroutines.

  Versiones anteriores de estas características fueron propuestas en PEP 288 por Raymond Hettinger y PEP 325 por Samuele Pedroni.

https://en.wikipedia.org/wiki/Coroutine

  La entrada de Wikipedia para las coroutines.

https://web.archive.org/web/20160321211320/http://www.sidhe.org/~dan/blog/archives/000178.html

  Una explicación de las coroutines desde el punto de vista de Perl, escrita por Dan Sugalski.

## PEP 343: La declaración «con

La sentencia “`with`” aclara el código que antes utilizaba bloques `try...finally`” para asegurar que se ejecuta el código de limpieza. En esta sección, hablaré de la sentencia tal y como se utiliza habitualmente. En la siguiente sección, examinaré los detalles de la implementación y mostraré cómo escribir objetos para usar con esta sentencia.

La declaración “`with`” es una nueva estructura de flujo de control cuya estructura básica es:

    with expression [as variable]:
        with-block

La expresión se evalúa y debe dar como resultado un objeto que soporte el protocolo de gestión de contextos (es decir, que tenga los métodos `__enter__()` y `__exit__()`).

El `__enter__()` del objeto es llamado antes de que se ejecute with-block y por lo tanto puede ejecutar código de configuración. También puede devolver un valor ligado al nombre variable, si se da. (Observe cuidadosamente que a variable no se le asigna el resultado de la expresión)

Una vez finalizada la ejecución del with-block, se llama al método `__exit__()` del objeto, incluso si el bloque lanzó una excepción, y por lo tanto puede ejecutar código de limpieza.

Para habilitar la declaración en Python 2.5, debe añadir la siguiente directiva a su módulo:

    from __future__ import with_statement

La declaración siempre estará habilitada en Python 2.6.

Algunos objetos estándar de Python soportan ahora el protocolo de gestión de contextos y pueden utilizarse con la sentencia “`with`””. Los objetos de archivo son un ejemplo:

    with open('/etc/passwd', 'r') as f:
        for line in f:
            print line
            ... more processing code ...

Después de que esta sentencia se haya ejecutado, el objeto archivo en f se habrá cerrado automáticamente, incluso si el bucle `for` lanzó una excepción a mitad del bloque.

Nota

En este caso, f es el mismo objeto creado por `open()`, porque `file.__enter__()` devuelve self.

Los bloqueos y las variables de condición del módulo `threading` también soportan la sentencia “`with`”:

    lock = threading.Lock()
    with lock:
        # Critical section of code
        ...

El bloqueo se adquiere antes de que se ejecute el bloque y siempre se libera una vez que el bloque se ha completado.

La nueva función `localcontext()` del módulo `decimal` facilita el guardado y la restauración del contexto decimal actual, que encapsula las características de precisión y redondeo deseadas para los cálculos:

    from decimal import Decimal, Context, localcontext

    # Displays with default precision of 28 digits
    v = Decimal('578')
    print v.sqrt()

    with localcontext(Context(prec=16)):
        # All code in this block uses a precision of 16 digits.
        # The original context is restored on exiting the block.
        print v.sqrt()

### Redacción de Gestores de Contexto

Bajo el capó, la sentencia “`with`” es bastante complicada. La mayoría de la gente sólo utilizará “`with`” en compañía de objetos existentes y no necesita conocer estos detalles, así que puedes saltarte el resto de esta sección si quieres. Los autores de nuevos objetos necesitarán entender los detalles de la implementación subyacente y deberían seguir leyendo.

Una explicación de alto nivel del protocolo de gestión del contexto es:

- La expresión se evalúa y debe dar como resultado un objeto llamado «gestor de contexto». El gestor de contexto debe tener métodos `__enter__()` y `__exit__()`.

- Se llama al método `__enter__()` del gestor de contexto. El valor devuelto se asigna a VAR. Si no está presente la cláusula `'as VAR'`, el valor simplemente se descarta.

- Se ejecuta el código en BLOQUE.

- Si BLOCK lanza una excepción, se llama a `__exit__(type, value, traceback)` con los detalles de la excepción, los mismos valores devueltos por `sys.exc_info()`. El valor de retorno del método controla si la excepción se vuelve a lanzar: cualquier valor falso vuelve a lanzar la excepción, y `True` resultará en suprimirla. Sólo en raras ocasiones querrá suprimir la excepción, porque si lo hace el autor del código que contiene la declaración “`with`” nunca se dará cuenta de que algo ha ido mal.

- Si BLOCK no lanzó una excepción, el método `__exit__()` sigue siendo llamado, pero type, value, y traceback son todos `None`.

Pensemos en un ejemplo. No presentaré un código detallado, sino que sólo esbozaré los métodos necesarios para una base de datos que soporte transacciones.

(Para quienes no estén familiarizados con la terminología de las bases de datos: un conjunto de cambios en la base de datos se agrupa en una transacción. Las transacciones pueden ser confirmadas, lo que significa que todos los cambios se escriben en la base de datos, o revertidas, lo que significa que todos los cambios se descartan y la base de datos no se modifica. Consulte cualquier libro de texto sobre bases de datos para obtener más información)

Supongamos que hay un objeto que representa una conexión a la base de datos. Nuestro objetivo será permitir que el usuario escriba código como este:

    db_connection = DatabaseConnection()
    with db_connection as cursor:
        cursor.execute('insert into ...')
        cursor.execute('delete from ...')
        # ... more operations ...

La transacción debe ser confirmada si el código en el bloque se ejecuta sin problemas o revertida si hay una excepción. Aquí está la interfaz básica para `DatabaseConnection` que voy a asumir:

    class DatabaseConnection:
        # Database interface
        def cursor (self):
            "Returns a cursor object and starts a new transaction"
        def commit (self):
            "Commits current transaction"
        def rollback (self):
            "Rolls back current transaction"

El método `__enter__()` es bastante sencillo, ya que sólo hay que iniciar una nueva transacción. Para esta aplicación el objeto cursor resultante sería un resultado útil, por lo que el método lo devolverá. El usuario puede entonces añadir `as cursor` a su sentencia “`with`” para ligar el cursor a un nombre de variable.

    class DatabaseConnection:
        ...
        def __enter__ (self):
            # Code to start a new transaction
            cursor = self.cursor()
            return cursor

El método `__exit__()` es el más complicado porque es donde hay que hacer la mayor parte del trabajo. El método tiene que comprobar si se produjo una excepción. Si no hubo ninguna excepción, la transacción es confirmada. La transacción es revertida si hubo una excepción.

En el código de abajo, la ejecución simplemente caerá al final de la función, devolviendo el valor por defecto de `None`. `None` es falso, por lo que la excepción se volverá a lanzar automáticamente. Si lo desea, puede ser más explícito y añadir una declaración `return` en el lugar marcado.

    class DatabaseConnection:
        ...
        def __exit__ (self, type, value, tb):
            if tb is None:
                # No exception, so commit
                self.commit()
            else:
                # Exception occurred, so rollback.
                self.rollback()
                # return False

### El módulo contextlib

El nuevo módulo `contextlib` proporciona algunas funciones y un decorador que son útiles para escribir objetos para usar con la sentencia “`with`”.

El decorador se llama `contextmanager()`, y permite escribir una única función generadora en lugar de definir una nueva clase. El generador debe producir exactamente un valor. El código hasta la palabra clave `yield` se ejecutará como el método `__enter__()`, y el valor producido será el valor de retorno del método que se vinculará a la variable en la cláusula `with` de la sentencia `as`, si existe. El código después de `yield` se ejecutará en el método `__exit__()`. Cualquier excepción lanzada en el bloque será lanzada por la sentencia `yield`.

Nuestro ejemplo de base de datos de la sección anterior podría escribirse utilizando este decorador como:

    from contextlib import contextmanager

    @contextmanager
    def db_transaction (connection):
        cursor = connection.cursor()
        try:
            yield cursor
        except:
            connection.rollback()
            raise
        else:
            connection.commit()

    db = DatabaseConnection()
    with db_transaction(db) as cursor:
        ...

El módulo `contextlib` también tiene una función `anidada(mgr1, mgr2, ...)` que combina varios gestores de contexto para que no sea necesario escribir sentencias “`with`” anidadas. En este ejemplo, la única sentencia “`with`` inicia una transacción de base de datos y adquiere un bloqueo de hilo:

    lock = threading.Lock()
    with nested (db_transaction(db), lock) as (cursor, locked):
        ...

Por último, la función `closing(object)` devuelve el objeto para que pueda ser vinculado a una variable, y llama a `object.close` al final del bloque.

    import urllib, sys
    from contextlib import closing

    with closing(urllib.urlopen('http://www.yahoo.com')) as f:
        for line in f:
            sys.stdout.write(line)

Ver también

PEP 343 - La declaración «con»

  PEP escrito por Guido van Rossum y Nick Coghlan; implementado por Mike Bland, Guido van Rossum y Neal Norwitz. El PEP muestra el código generado para una sentencia “`with`”, que puede ser útil para aprender cómo funciona la sentencia.

La documentación del módulo `contextlib`.

## PEP 352: Las excepciones como clases de nuevo estilo

Las clases de excepción ahora pueden ser clases de nuevo estilo, no sólo clases clásicas, y la clase incorporada `Exception` y todas las excepciones incorporadas estándar (`NameError`, `ValueError`, etc.) son ahora clases de nuevo estilo.

La jerarquía de herencia de las excepciones se ha reordenado un poco. En 2.5, las relaciones de herencia son:

    BaseException       # New in Python 2.5
    |- KeyboardInterrupt
    |- SystemExit
    |- Exception
       |- (all other current built-in exceptions)

Esta reorganización se hizo porque la gente a menudo quiere atrapar todas las excepciones que indican errores del programa. `KeyboardInterrupt` y `SystemExit` no son errores, sin embargo, y por lo general representan una acción explícita como el usuario pulsando ``Control`-`C`` o el código llamando a `sys.exit()`. Una simple `except:` atrapará todas las excepciones, por lo que comúnmente se necesita listar `KeyboardInterrupt` y `SystemExit` para volver a lanzarlas. El patrón habitual es:

    try:
        ...
    except (KeyboardInterrupt, SystemExit):
        raise
    except:
        # Log error...
        # Continue running program...

En Python 2.5, ahora puedes escribir `except Exception` para conseguir el mismo resultado, capturando todas las excepciones que suelen indicar errores pero dejando `KeyboardInterrupt` y `SystemExit` en paz. Como en versiones anteriores, un `except:` desnudo sigue capturando todas las excepciones.

El objetivo de Python 3.0 es requerir que cualquier clase lanzada como excepción derive de `BaseException` o de algún descendiente de `BaseException`, y las futuras versiones de la serie Python 2.x pueden empezar a imponer esta restricción. Por lo tanto, sugiero que empieces a hacer que todas tus clases de excepción deriven de `Exception` ahora. Se ha sugerido que la forma desnuda `except:` sea eliminada en Python 3.0, pero Guido van Rossum no ha decidido si hacerlo o no.

El lanzamiento de cadenas como excepciones, como en la declaración `raise "Error occurred"`, está obsoleto en Python 2.5 y provocará una advertencia. El objetivo es poder eliminar la función de excepción de cadena en algunas versiones.

Ver también

PEP 352 - Superclase necesaria para las excepciones

  PEP escrito por Brett Cannon y Guido van Rossum; implementado por Brett Cannon.

## PEP 353: Uso de ssize_t como tipo de índice

Un amplio cambio en la API C de Python, que utiliza una nueva definición de tipo `Py_ssize_t` en lugar de int, permitirá al intérprete manejar más datos en plataformas de 64 bits. Este cambio no afecta a la capacidad de Python en plataformas de 32 bits.

Varias partes del intérprete de Python utilizaban el tipo int de C para almacenar tamaños o recuentos; por ejemplo, el número de elementos de una lista o tupla se almacenaba en un int. Los compiladores de C para la mayoría de las plataformas de 64 bits siguen definiendo int como un tipo de 32 bits, lo que significa que las listas sólo pueden contener hasta `2**31 - 1` = 2147483647 elementos. (En realidad, hay algunos modelos de programación diferentes que los compiladores de C de 64 bits pueden utilizar – véase http://www.unix.org/version2/whatsnew/lp64_wp.html para una discusión – pero el modelo más comúnmente disponible deja int como de 32 bits)

Un límite de 2147483647 elementos no importa realmente en una plataforma de 32 bits porque te quedarás sin memoria antes de alcanzar el límite de longitud. Cada elemento de la lista requiere espacio para un puntero, que es de 4 bytes, más espacio para un `PyObject` que representa el elemento. 2147483647*4 ya son más bytes de los que puede contener un espacio de direcciones de 32 bits.

Sin embargo, es posible direccionar esa cantidad de memoria en una plataforma de 64 bits. Los punteros para una lista de ese tamaño sólo requerirían 16 GiB de espacio, por lo que no es descabellado que los programadores de Python puedan construir listas tan grandes. Por lo tanto, el intérprete de Python tuvo que ser cambiado para usar algún tipo diferente a int, y este será un tipo de 64 bits en plataformas de 64 bits. El cambio causará incompatibilidades en las máquinas de 64 bits, por lo que se consideró que valía la pena hacer la transición ahora, mientras el número de usuarios de 64 bits es todavía relativamente pequeño. (En 5 o 10 años, puede que todos estemos en máquinas de 64 bits, y la transición sería entonces más dolorosa)

Este cambio afecta en mayor medida a los autores de módulos de extensión de C. Las cadenas de Python y los tipos contenedores como las listas y las tuplas utilizan ahora `Py_ssize_t` para almacenar su tamaño. Funciones como `PyList_Size()` ahora devuelven `Py_ssize_t`. Por lo tanto, el código de los módulos de extensión puede necesitar cambiar algunas variables a `Py_ssize_t`.

Las funciones `PyArg_ParseTuple()` y `Py_BuildValue()` tienen un nuevo código de conversión, `n`, para `Py_ssize_t`. Las funciones `PyArg_ParseTuple()` `s#` y `t#` siguen devolviendo int por defecto, pero puedes definir la macro `PY_SSIZE_T_CLEAN` antes de incluir `Python.h` para que devuelvan `Py_ssize_t`.

PEP 353 tiene una sección sobre directrices de conversión que los autores de extensiones deberían leer para aprender a soportar plataformas de 64 bits.

Ver también

PEP 353 - Uso de ssize_t como tipo de índice

  PEP escrito y aplicado por Martin von Löwis.

## PEP 357: El método “__index__”

Los desarrolladores de NumPy tenían un problema que sólo podía resolverse añadiendo un nuevo método especial, `__index__()`. Cuando se utiliza la notación de trozos, como en `[start:stop:step]`, los valores de los índices start, stop y step deben ser todos enteros o enteros largos. NumPy define una variedad de tipos de enteros especializados que corresponden a enteros sin signo y con signo de 8, 16, 32 y 64 bits, pero no había forma de señalar que estos tipos pudieran usarse como índices de trozos.

El rebanado no puede utilizar el método `__int__()` existente porque ese método también se utiliza para implementar la coerción a enteros. Si el rebanado utilizara `__int__()`, los números de punto flotante también se convertirían en índices de rebanada legales y eso es claramente un comportamiento indeseable.

En su lugar, se ha añadido un nuevo método especial llamado `__index__()`. No toma argumentos y devuelve un entero que da el índice de corte a utilizar. Por ejemplo:

    class C:
        def __index__ (self):
            return self.value

El valor devuelto debe ser un entero de Python o un entero largo. El intérprete comprobará que el tipo devuelto es correcto, y lanza un `TypeError` si no se cumple este requisito.

Se ha añadido la correspondiente ranura `nb_index` a la estructura `PyNumberMethods` de nivel C para que las extensiones C puedan implementar este protocolo. El código de la extensión puede utilizar `PyNumber_Index(obj)` para llamar a la función `__index__()` y obtener su resultado.

Ver también

PEP 357 - Permitir el uso de cualquier objeto para rebanar

  PEP escrito e implementado por Travis Oliphant.

## Otros cambios lingüísticos

Estos son todos los cambios que Python 2.5 introduce en el núcleo del lenguaje Python.

- El tipo `dict` tiene un nuevo gancho para permitir que las subclases proporcionen un valor por defecto cuando una clave no está contenida en el diccionario. Cuando no se encuentre una clave, se llamará al método `missing__(key)` del diccionario. Este hook se utiliza para implementar la nueva clase `defaultdict` en el módulo `collections`. El siguiente ejemplo define un diccionario que devuelve cero para cualquier clave que falte:

      class zerodict (dict):
          def __missing__ (self, key):
              return 0

      d = zerodict({1:1, 2:2})
      print d[1], d[2]   # Prints 1, 2
      print d[3], d[4]   # Prints 0, 0

- Tanto las cadenas de 8 bits como las de Unicode tienen nuevos métodos `partition(sep)` y `rpartition(sep)` que simplifican un caso de uso común.

  El método `find(S)` se utiliza a menudo para obtener un índice que luego se utiliza para cortar la cadena y obtener las piezas que están antes y después del separador. El método `partition(sep)` condensa este patrón en una sola llamada al método que devuelve una tripleta que contiene la subcadena antes del separador, el propio separador y la subcadena después del separador. Si no se encuentra el separador, el primer elemento de la tupla es la cadena completa y los otros dos elementos están vacíos. `rpartition(sep)` también devuelve una tupla de 3 elementos, pero empieza a buscar desde el final de la cadena; la `r` significa «al revés».

  Algunos ejemplos:

      >>> ('http://www.python.org').partition('://')
      ('http', '://', 'www.python.org')
      >>> ('file:/usr/share/doc/index.html').partition('://')
      ('file:/usr/share/doc/index.html', '', '')
      >>> (u'Subject: a quick question').partition(':')
      (u'Subject', u':', u' a quick question')
      >>> 'www.python.org'.rpartition('.')
      ('www.python', '.', 'org')
      >>> 'www.python.org'.rpartition(':')
      ('', '', 'www.python.org')

  (Implementado por Fredrik Lundh tras una sugerencia de Raymond Hettinger)

- Los métodos `startswith()` y `endswith()` de los tipos de cadena aceptan ahora tuplas de cadenas para su comprobación.

      def is_image_file (filename):
          return filename.endswith(('.gif', '.jpg', '.tiff'))

  (Implementado por Georg Brandl tras una sugerencia de Tom Lynn)

- Las funciones incorporadas `min()` y `max()` han ganado un parámetro de palabra clave `key` análogo al argumento `key` de `sort()`. Este parámetro proporciona una función que toma un único argumento y es llamada para cada valor de la lista; `min()`/`max()` devolverá el elemento con el valor de retorno más pequeño/más grande de esta función. Por ejemplo, para encontrar la cadena más larga de una lista, puede hacer:

      L = ['medium', 'longest', 'short']
      # Prints 'longest'
      print max(L, key=len)
      # Prints 'short', because lexicographically 'short' has the largest value
      print max(L)

  (Contribución de Steven Bethard y Raymond Hettinger)

- Dos nuevas funciones incorporadas, `any()` y `all()`, evalúan si un iterador contiene algún valor verdadero o falso. `any()` devuelve `True` si cualquier valor devuelto por el iterador es verdadero; en caso contrario devolverá `False`. `all()` devuelve `True` sólo si todos los valores devueltos por el iterador se evalúan como verdaderos. (Sugerido por Guido van Rossum, e implementado por Raymond Hettinger)

- El resultado del método `__hash__()` de una clase puede ser ahora un entero largo o un entero normal. Si se devuelve un entero largo, se toma el hash de ese valor. En versiones anteriores se requería que el valor del hash fuera un entero regular, pero en 2.5 el built-in `id()` se cambió para devolver siempre números no negativos, y los usuarios parecen utilizar a menudo `id(self)` en los métodos `__hash__()` (aunque esto se desaconseja).

- ASCII es ahora la codificación por defecto para los módulos. Ahora es un error de sintaxis si un módulo contiene literales de cadena con caracteres de 8 bits pero no tiene una declaración de codificación. En Python 2.4 esto provocaba una advertencia, no un error de sintaxis. Vea en PEP 263 cómo declarar la codificación de un módulo; por ejemplo, puede añadir una línea como ésta cerca de la parte superior del fichero fuente:

      # -*- coding: latin1 -*-

- Una nueva advertencia, `UnicodeWarning`, se activa cuando se intenta comparar una cadena Unicode y una cadena de 8 bits que no se puede convertir a Unicode utilizando la codificación ASCII por defecto. El resultado de la comparación es falso:

      >>> chr(128) == unichr(128)   # Can't convert chr(128) to Unicode
      __main__:1: UnicodeWarning: Unicode equal comparison failed
        to convert both arguments to Unicode - interpreting them
        as being unequal
      False
      >>> chr(127) == unichr(127)   # chr(127) can be converted
      True

  Anteriormente, esto lanzaba una excepción `UnicodeDecodeError`, pero en 2.5 esto podía dar lugar a problemas desconcertantes al acceder a un diccionario. Si se buscaba `unichr(128)` y se utilizaba `chr(128)` como clave, se producía una excepción `UnicodeDecodeError`. Otros cambios en la versión 2.5 hicieron que esta excepción se lanzara en lugar de ser suprimida por el código de `dictobject.c` que implementa los diccionarios.

  Lanzar una excepción para tal comparación es estrictamente correcto, pero el cambio podría haber roto el código, así que en su lugar se introdujo `UnicodeWarning`.

  (Implementado por Marc-André Lemburg.)

- Un error que a veces cometen los programadores de Python es olvidarse de incluir un módulo `__init__.py` en el directorio de un paquete. Depurar este error puede ser confuso, y normalmente requiere ejecutar Python con el modificador `-v` para registrar todas las rutas buscadas. En Python 2.5, una nueva advertencia `ImportWarning` se activa cuando una importación habría recogido un directorio como paquete pero no se encontró ningún `__init__.py`. Esta advertencia se ignora silenciosamente por defecto; proporcione la opción `-Wd` cuando ejecute el ejecutable de Python para mostrar el mensaje de advertencia. (Implementado por Thomas Wouters)</-W>

- La lista de clases base en una definición de clase ahora puede estar vacía. Como ejemplo, esto es ahora legal:

      class C():
          pass

  (Implementado por Brett Cannon.)

### Cambios en el intérprete interactivo

En el intérprete interactivo, `quit` y `exit` han sido durante mucho tiempo cadenas para que los nuevos usuarios obtengan un mensaje algo útil cuando intenten salir:

    >>> quit
    'Use Ctrl-D (i.e. EOF) to exit.'

En Python 2.5, `quit` y `exit` son ahora objetos que siguen produciendo representaciones de cadena de sí mismos, pero también son invocables. Los novatos que prueben `quit()` o `exit()` ahora saldrán del intérprete como se espera. (Implementado por Georg Brandl.)

El ejecutable de Python ahora acepta las opciones largas estándar `--help` y `--version`; en Windows, también acepta la opción `/?` para mostrar un mensaje de ayuda. (Implementado por Georg Brandl)

### Optimizaciones

Varias de las optimizaciones se desarrollaron en el sprint NeedForSpeed, un evento celebrado en Reikiavik, Islandia, del 21 al 28 de mayo de 2006. El sprint se centró en las mejoras de velocidad de la implementación de CPython y fue financiado por EWT LLC con el apoyo local de CCP Games. Las optimizaciones añadidas en este sprint están especialmente marcadas en la siguiente lista.

- Cuando se introdujeron en Python 2.4, los tipos incorporados `set` y `frozenset` se construyeron sobre el tipo diccionario de Python. En 2.5 la estructura de datos interna se ha personalizado para implementar conjuntos, y como resultado los conjuntos utilizarán un tercio menos de memoria y son algo más rápidos. (Implementado por Raymond Hettinger)

- Se ha mejorado la velocidad de algunas operaciones Unicode, como la búsqueda de subcadenas, la división de cadenas y la codificación y decodificación de mapas de caracteres. (Las mejoras en la búsqueda de subcadenas y la división fueron añadidas por Fredrik Lundh y Andrew Dalke en el sprint NeedForSpeed. Los mapas de caracteres fueron mejorados por Walter Dörwald y Martin von Löwis)

- La función `long(str, base)` es ahora más rápida en cadenas de dígitos largos porque se calculan menos resultados intermedios. El máximo es para cadenas de alrededor de 800-1000 dígitos, donde la función es 6 veces más rápida. (Aportado por Alan McIntyre y comprometido en el sprint NeedForSpeed)

- Ahora es ilegal mezclar la iteración sobre un fichero con `for line in file` y llamar a los métodos `read()`/`readline()`/`readlines()` del objeto fichero. La iteración utiliza un buffer interno y los métodos `read*()` no utilizan ese buffer. En su lugar, devolverán los datos que siguen al buffer, haciendo que los datos aparezcan desordenados. Mezclar la iteración y estos métodos provocará ahora un `ValueError` del método `read*()`. (Implementado por Thomas Wouters)

- El módulo `struct` ahora compila cadenas de formato de estructura en una representación interna y almacena en caché esta representación, lo que supone una mejora del 20% s. (Contribuido por Bob Ippolito en el sprint NeedForSpeed)

- El módulo `re` obtuvo un 1 o 2% s de velocidad al cambiar a las funciones asignadoras de Python en lugar de las `malloc()` y `free()` del sistema. (Contribuido por Jack Diederich en el sprint NeedForSpeed)

- El optimizador de la mirilla del generador de código realiza ahora un simple plegado de constantes en las expresiones. Si escribes algo como `a = 2+3`, el generador de código hará la aritmética y producirá el código correspondiente a `a = 5`. (Propuesto e implementado por Raymond Hettinger)

- Las llamadas a funciones son ahora más rápidas porque los objetos de código guardan ahora el último fotograma terminado (un «fotograma zombi») en un campo interno del objeto de código, reutilizándolo la próxima vez que se invoque el objeto de código. (Parche original de Michael Hudson, modificado por Armin Rigo y Richard Jones; confirmado en el sprint NeedForSpeed) Los objetos marco son también ligeramente más pequeños, lo que puede mejorar la localidad de la caché y reducir un poco el uso de la memoria. (Contribución de Neal Norwitz)

- Las excepciones incorporadas en Python son ahora clases de nuevo estilo, un cambio que acelera considerablemente la instanciación. El manejo de excepciones en Python 2.5 es, por tanto, un 30% f más rápido que en 2.4. (Contribución de Richard Jones, Georg Brandl y Sean Reifschneider en el sprint NeedForSpeed)

- La importación ahora almacena en caché las rutas intentadas, registrando si existen o no para que el intérprete haga menos llamadas a `open()` y `stat()` al iniciar. (Contribución de Martin von Löwis y Georg Brandl)

## Módulos nuevos, mejorados y eliminados

La biblioteca estándar ha recibido muchas mejoras y correcciones de errores en Python 2.5. Aquí hay una lista parcial de los cambios más notables, ordenados alfabéticamente por el nombre del módulo. Consulte el archivo `Misc/NEWS` en el árbol de fuentes para obtener una lista más completa de los cambios, o busque en los registros de SVN para obtener todos los detalles.

- El módulo `audioop` soporta ahora la codificación a-LAW, y se ha mejorado el código para la codificación u-LAW. (Contribución de Lars Immisch)

- El módulo `codecs` ha ganado soporte para códecs incrementales. La función `codec.lookup()` devuelve ahora una instancia de `CodecInfo` en lugar de una tupla. Las instancias de `CodecInfo` se comportan como una cuádruple tupla para preservar la compatibilidad con versiones anteriores, pero también tienen los atributos `encode`, `decode`, `incrementalencoder`, `incrementaldecoder`, `streamwriter` y `streamreader`. Los códecs incrementales pueden recibir la entrada y producir la salida en varios trozos; la salida es la misma que si la entrada completa fuera alimentada por el códec no incremental. Consulte la documentación del módulo `codecs` para más detalles. (Diseñado e implementado por Walter Dörwald)

- El módulo `collections` ha ganado un nuevo tipo, `defaultdict`, que subclasifica el tipo estándar `dict`. El nuevo tipo se comporta principalmente como un diccionario pero construye un valor por defecto cuando una clave no está presente, añadiéndolo automáticamente al diccionario para el valor de la clave solicitada.

  El primer argumento del constructor de `defaultdict` es una función de fábrica que se llama cada vez que se solicita una clave pero no se encuentra. Esta función de fábrica no recibe argumentos, por lo que puede utilizar constructores de tipo incorporado como `list()` o `int()`. Por ejemplo, puedes hacer un índice de palabras basado en su letra inicial así:

      words = """Nel mezzo del cammin di nostra vita
      mi ritrovai per una selva oscura
      che la diritta via era smarrita""".lower().split()

      index = defaultdict(list)

      for w in words:
          init_letter = w[0]
          index[init_letter].append(w)

  Al imprimir `index` se obtiene la siguiente salida:

      defaultdict(<type 'list'>, {'c': ['cammin', 'che'], 'e': ['era'],
              'd': ['del', 'di', 'diritta'], 'm': ['mezzo', 'mi'],
              'l': ['la'], 'o': ['oscura'], 'n': ['nel', 'nostra'],
              'p': ['per'], 's': ['selva', 'smarrita'],
              'r': ['ritrovai'], 'u': ['una'], 'v': ['vita', 'via']}

  (Contribución de Guido van Rossum.)

- El tipo de cola doble `deque` suministrado por el módulo `collections` tiene ahora un método `remove(value)` que elimina la primera aparición de value en la cola, lanzando `ValueError` si no se encuentra el valor. (Contribución de Raymond Hettinger)

- Nuevo módulo: El módulo `contextlib` contiene funciones de ayuda para usar con la nueva sentencia “`with`”. Consulte la sección El módulo contextlib para obtener más información sobre este módulo.

- Nuevo módulo: El módulo `cProfile` es una implementación en C del módulo existente `profile` que tiene una sobrecarga mucho menor. La interfaz del módulo es la misma que la de `profile`: se ejecuta `cProfile.run('main()')` para perfilar una función, se pueden guardar los datos del perfil en un archivo, etc. Todavía no se sabe si el perfilador Hotshot, que también está escrito en C pero no coincide con la interfaz del módulo `profile`, seguirá manteniéndose en futuras versiones de Python. (Contribución de Armin Rigo.)

  Además, el módulo `pstats` para analizar los datos medidos por el perfilador ahora soporta dirigir la salida a cualquier objeto archivo suministrando un argumento stream al constructor `Stats`. (Contribución de Skip Montanaro)

- The `csv` module, which parses files in comma-separated value format, received several enhancements and a number of bugfixes. You can now set the maximum size in bytes of a field by calling the `csv.field_size_limit(new_limit)` function; omitting the new_limit argument will return the currently set limit. The `reader` class now has a `line_num` attribute that counts the number of physical lines read from the source; records can span multiple physical lines, so `line_num` is not the same as the number of records read.

  El analizador CSV es ahora más estricto con los campos entrecomillados de varias líneas. Anteriormente, si una línea terminaba dentro de un campo entre comillas sin un carácter de nueva línea final, se insertaba una nueva línea en el campo devuelto. Este comportamiento causaba problemas cuando se leían archivos que contenían caracteres de retorno de carro dentro de los campos, por lo que se cambió el código para devolver el campo sin insertar nuevas líneas. Como consecuencia, si las nuevas líneas incrustadas dentro de los campos son importantes, la entrada debe dividirse en líneas de manera que se conserven los caracteres de nueva línea.

  (Contribución de Skip Montanaro y Andrew McNamara)

- La clase `datetime` del módulo `datetime` tiene ahora un método `strptime(string, format)` para analizar cadenas de fechas, aportado por Josh Spoerri. Utiliza los mismos caracteres de formato que `time.strptime()` y `time.strftime()`:

      from datetime import datetime

      ts = datetime.strptime('10:13:15 2006-03-07',
                             '%H:%M:%S %Y-%m-%d')

- El método `SequenceMatcher.get_matching_blocks()` del módulo `difflib` garantiza ahora la devolución de una lista mínima de bloques que describen subsecuencias coincidentes. Anteriormente, el algoritmo rompía ocasionalmente un bloque de elementos coincidentes en dos entradas de la lista. (Mejora realizada por Tim Peters)

- El módulo `doctest` ha ganado una opción `SKIP` que impide que un ejemplo se ejecute en absoluto. Esto está pensado para los fragmentos de código que son ejemplos de uso destinados al lector y que no son realmente casos de prueba.

  Se ha añadido un parámetro encoding a la función `testfile()` y a la clase `DocFileSuite` para especificar la codificación del archivo. Esto facilita el uso de caracteres no ASCII en las pruebas contenidas en un docstring. (Contribución de Bjorn Tillenius)

- El paquete `email` ha sido actualizado a la versión 4.0. (Contribución de Barry Warsaw.)

- El módulo `fileinput` se ha hecho más flexible. Ahora se soportan los nombres de archivo Unicode, y se ha añadido un parámetro mode que por defecto es `"r"` a la función `input()` para permitir la apertura de archivos en modo binario o universal newlines. Otro nuevo parámetro, openhook, permite utilizar una función distinta de `open()` para abrir los ficheros de entrada. Una vez que se itera sobre el conjunto de archivos, el nuevo `fileno()` del objeto `FileInput` devuelve el descriptor de archivo del archivo actualmente abierto. (Contribuido por Georg Brandl.)

- En el módulo `gc`, la nueva función `get_count()` devuelve una 3-tupla que contiene los recuentos de recolección actuales para las tres generaciones de GC. Se trata de información contable para el recolector de basura; cuando estos recuentos alcanzan un umbral especificado, se realiza un barrido de recolección de basura. La función `gc.collect()` existente ahora toma un argumento opcional generación de 0, 1 o 2 para especificar qué generación recoger. (Contribución de Barry Warsaw)

- Las funciones `nsmallest()` y `nlargest()` del módulo `heapq` soportan ahora un parámetro de palabra clave `key` similar al proporcionado por las funciones `min()`/`max()` y los métodos `sort()`. Por ejemplo:

      >>> import heapq
      >>> L = ["short", 'medium', 'longest', 'longer still']
      >>> heapq.nsmallest(2, L)  # Return two lowest elements, lexicographically
      ['longer still', 'longest']
      >>> heapq.nsmallest(2, L, key=len)   # Return two shortest elements
      ['short', 'medium']

  (Contribución de Raymond Hettinger.)

- La función `itertools.islice()` ahora acepta `None` para los argumentos de inicio y paso. Esto la hace más compatible con los atributos de los objetos slice, por lo que ahora se puede escribir lo siguiente:

      s = slice(5)     # Create slice object
      itertools.islice(iterable, s.start, s.stop, s.step)

  (Contribución de Raymond Hettinger.)

- Se ha modificado la función `format()` del módulo `locale` y se han añadido dos nuevas funciones, `format_string()` y `currency()`.

  El parámetro val de la función `format()` podía ser antes una cadena siempre que no apareciera más de un especificador %char; ahora el parámetro debe ser exactamente un especificador %char sin texto alrededor. También se ha añadido un parámetro opcional monetario que, si es `Verdadero`, utilizará las reglas de la configuración regional para formatear la moneda al colocar un separador entre grupos de tres dígitos.

  Para formatear cadenas con múltiples especificadores %char, utilice la nueva función `format_string()` que funciona como `format()` pero que también permite mezclar especificadores %char con texto arbitrario.

  También se ha añadido una nueva función `currency()` que formatea un número de acuerdo con la configuración local actual.

  (Contribución de Georg Brandl.)

- El módulo `mailbox` ha sido reestructurado de forma masiva para añadir la capacidad de modificar los buzones además de leerlos. Un nuevo conjunto de clases que incluyen `mbox`, `MH`, y `Maildir` se utilizan para leer buzones, y tienen un método `add(message)` para añadir mensajes, `remove(key)` para eliminar mensajes, y `lock()`/`unlock()` para bloquear/desbloquear el buzón. El siguiente ejemplo convierte un buzón con formato maildir en uno con formato mbox:

      import mailbox

      # 'factory=None' uses email.Message.Message as the class representing
      # individual messages.
      src = mailbox.Maildir('maildir', factory=None)
      dest = mailbox.mbox('/tmp/mbox')

      for msg in src:
          dest.add(msg)

  (Contribución de Gregory K. Johnson. La financiación fue proporcionada por el Summer of Code 2005 de Google)

- Nuevo módulo: el módulo `msilib` permite crear archivos `.msi` de Microsoft Installer y archivos CAB. También se incluye soporte para la lectura de la base de datos `.msi`. (Contribución de Martin von Löwis)

- El módulo `nis` soporta ahora el acceso a dominios distintos del dominio por defecto del sistema proporcionando un argumento dominio a las funciones `nis.match()` y `nis.maps()`. (Contribución de Ben Bell)

- Las funciones `operator` del módulo `itemgetter()` y `attrgetter()` ahora soportan múltiples campos. Una llamada como `operator.attrgetter('a', 'b')` devolverá una función que recupera los atributos `a` y `b`. La combinación de esta nueva función con el parámetro `key` del método `sort()` permite ordenar fácilmente las listas utilizando varios campos. (Contribución de Raymond Hettinger)

- El módulo `optparse` se ha actualizado a la versión 1.5.1 de la biblioteca Optik. La clase `OptionParser` obtuvo un atributo `epilog`, una cadena que se imprimirá después del mensaje de ayuda, y un método `destroy()` para romper los ciclos de referencia creados por el objeto. (Contribuido por Greg Ward.)

- El módulo `os` ha sufrido varios cambios. La variable `stat_float_times` ahora está predeterminada a true, lo que significa que `os.stat()` ahora devolverá los valores de tiempo como flotantes. (Esto no significa necesariamente que `os.stat()` devolverá tiempos con una precisión de fracciones de segundo; no todos los sistemas soportan dicha precisión)

  Se han añadido las constantes `os.SEEK_SET`, `os.SEEK_CUR` y `os.SEEK_END`, que son los parámetros de la función `os.lseek()`. Dos nuevas constantes para el bloqueo son `os.O_SHLOCK` y `os.O_EXLOCK`.

  Se han añadido dos nuevas funciones, `wait3()` y `wait4()`. Son similares a la función `waitpid()` que espera la salida de un proceso hijo y devuelve una tupla con el ID del proceso y su estado de salida, pero `wait3()` y `wait4()` devuelven información adicional. `wait3()` no toma un ID de proceso como entrada, por lo que espera a que cualquier proceso hijo salga y devuelve una tupla de id de proceso, estado de salida, uso de recursos tal y como se devuelve desde la función `resource.getrusage()`. `wait4(pid)` toma un ID de proceso. (Contribuido por Chad J. Schroeder.)

  En FreeBSD, la función `os.stat()` devuelve ahora tiempos con resolución de nanosegundos, y el objeto devuelto tiene ahora `st_gen` y `st_birthtime`. El atributo `st_flags` también está disponible, si la plataforma lo soporta. (Contribución de Antti Louko y Diego Pettenò)

- El depurador de Python proporcionado por el módulo `pdb` puede ahora almacenar listas de comandos a ejecutar cuando se alcanza un punto de ruptura y se detiene la ejecución. Una vez creado el punto de interrupción nº 1, introduzca `comandos 1` e introduzca una serie de comandos a ejecutar, terminando la lista con `end`. La lista de comandos puede incluir comandos que reanuden la ejecución, como `continue` o `next`. (Contribución de Grégoire Dooms.)

- Los módulos `pickle` y `cPickle` ya no aceptan un valor de retorno de `None` del método `__reduce__()`; el método debe devolver una tupla de argumentos. La capacidad de devolver `None` fue obsoleta en Python 2.4, así que esto completa la eliminación de la función.

- El módulo `pkgutil`, que contiene varias funciones de utilidad para encontrar paquetes, fue mejorado para soportar los ganchos de importación de PEP 302 y ahora también funciona para paquetes almacenados en archivos con formato ZIP. (Contribución de Phillip J. Eby)

- El conjunto de pruebas pybench de Marc-André Lemburg se incluye ahora en el directorio `Tools/pybench`. El conjunto de pruebas pybench es una mejora del programa `pystone.py` de uso común, ya que pybench proporciona una medición más detallada de la velocidad del intérprete. Calcula el tiempo de determinadas operaciones como las llamadas a funciones, el corte de tuplas, las búsquedas de métodos y las operaciones numéricas, en lugar de realizar muchas operaciones diferentes y reducir el resultado a un único número como hace `pystone.py`.

- El módulo `pyexpat` utiliza ahora la versión 2.0 del analizador sintáctico Expat. (Contribución de Trent Mick)

- La clase `Queue` proporcionada por el módulo `Queue` ha ganado dos nuevos métodos. `join()` bloquea hasta que todos los elementos de la cola han sido recuperados y todo el trabajo de procesamiento de los elementos ha sido completado. Los hilos de trabajo llaman al otro método nuevo, `task_done()`, para indicar que el procesamiento de un elemento ha finalizado. (Contribución de Raymond Hettinger)

- Los antiguos módulos `regex` y `regsub`, obsoletos desde Python 2.0, han sido finalmente eliminados. Otros módulos eliminados: `statcache`, `tzparse`, `whrandom`.

- También se ha eliminado el directorio `lib-old`, que incluye módulos antiguos como `dircmp` y `ni`. `lib-old` no estaba en el directorio por defecto `sys.path`, así que a menos que tus programas añadan explícitamente el directorio a `sys.path`, esta eliminación no debería afectar a tu código.

- El módulo `rlcompleter` ya no depende de la importación del módulo `readline` y, por lo tanto, ahora funciona en plataformas no Unix. (Parche de Robert Kiendl.)

- Las clases `SimpleXMLRPCServer` y `DocXMLRPCServer` tienen ahora un atributo `rpc_paths` que restringe las operaciones XML-RPC a un conjunto limitado de rutas URL; por defecto sólo se permiten `'/'` y `'/RPC2'`. Establecer `rpc_paths` como `None` o una tupla vacía desactiva esta comprobación de rutas.

- El módulo `socket` ahora soporta sockets `AF_NETLINK` en Linux, gracias a un parche de Philippe Biondi. Los sockets Netlink son un mecanismo específico de Linux para las comunicaciones entre un proceso en el espacio del usuario y el código del kernel; hay un artículo introductorio sobre ellos en https://www.linuxjournal.com/article/7356. En el código Python, las direcciones de netlink se representan como una tupla de 2 enteros, `(pid, group_mask)`.

  Dos nuevos métodos en objetos socket, `recv_into(buffer)` y `recvrom_into(buffer)`, almacenan los datos recibidos en un objeto que soporta el protocolo de buffer en lugar de devolver los datos como una cadena. Esto significa que puedes poner los datos directamente en un array o en un archivo mapeado en memoria.

  Los objetos Socket también han ganado métodos de acceso `getfamily()`, `gettype()` y `getproto()` para recuperar los valores de familia, tipo y protocolo del socket.

- Nuevo módulo: el módulo `spwd` proporciona funciones para acceder a la base de datos de contraseñas en la sombra en sistemas que soportan contraseñas en la sombra.

- El módulo `struct` es ahora más rápido porque compila cadenas de formato en objetos `Struct` con métodos `pack()` y `unpack()`. Esto es similar a cómo el módulo `re` permite crear objetos de expresión regular compilados. Puede seguir utilizando las funciones `pack()` y `unpack()` a nivel de módulo; éstas crearán objetos `Struct` y los almacenarán en caché. O puede utilizar directamente las instancias de `Struct`:

      s = struct.Struct('ih3s')

      data = s.pack(1972, 187, 'abc')
      year, number, name = s.unpack(data)

  También puedes empaquetar y desempaquetar datos hacia y desde objetos buffer directamente usando los métodos `pack_into(buffer, offset, v1, v2, ...)` y `unpack_from(buffer, offset)`. Esto te permite almacenar datos directamente en un array o en un archivo mapeado en memoria.

  (`Struct` objects fueron implementados por Bob Ippolito en el sprint NeedForSpeed. El soporte para los objetos buffer fue añadido por Martin Blais, también en el sprint NeedForSpeed)

- Los desarrolladores de Python cambiaron de CVS a Subversion durante el proceso de desarrollo de la versión 2.5. La información sobre la versión exacta de construcción está disponible como la variable `sys.subversion`, una 3-tupla de `(nombre del intérprete, nombre de la rama, rango de revisión)`. Por ejemplo, en el momento de escribir esto, mi copia de 2.5 informaba de `('CPython', 'trunk', '45313:45315')`.

  Esta información también está disponible para las extensiones de C a través de la función `Py_GetBuildInfo()` que devuelve una cadena de información de compilación como esta `"trunk:45355:45356M, Apr 13 2006, 07:42:19"`. (Contribuido por Barry Warsaw.)

- Otra nueva función, `sys._current_frames()`, devuelve los marcos de pila actuales para todos los hilos en ejecución como un diccionario que asigna los identificadores de los hilos al marco de pila superior actualmente activo en ese hilo en el momento en que se llama a la función. (Contribuido por Tim Peters.)

- La clase `TarFile` del módulo `tarfile` tiene ahora un método `extractall()` que extrae todos los miembros del archivo en el directorio de trabajo actual. También es posible establecer un directorio diferente como destino de la extracción, y desempaquetar sólo un subconjunto de los miembros del archivo.

  La compresión utilizada para un archivo tar abierto en modo stream puede ahora ser autodetectada utilizando el modo `'r|*'`. (Contribución de Lars Gustäbel)

- El módulo `threading` permite ahora establecer el tamaño de la pila utilizado cuando se crean nuevos hilos. La función `stack_size([*size*])` devuelve el tamaño de pila actualmente configurado, y suministrando el parámetro opcional size establece un nuevo valor. No todas las plataformas soportan el cambio del tamaño de la pila, pero Windows, POSIX threading y OS/2 lo hacen. (Contribución de Andrew MacIntyre)

- El módulo `unicodedata` ha sido actualizado para utilizar la versión 4.1.0 de la base de datos de caracteres Unicode. La versión 3.2.0 es requerida por algunas especificaciones, por lo que sigue estando disponible como `unicodedata.ucd_3_2_0`.

- Nuevo módulo: el módulo `uuid` genera identificadores únicos universales (UUID) de acuerdo con RFC 4122. El RFC define varias versiones diferentes de UUID que se generan a partir de una cadena inicial, de propiedades del sistema o de forma puramente aleatoria. Este módulo contiene una clase `UUID` y funciones llamadas `uuid1()`, `uuid3()`, `uuid4()`, y `uuid5()` para generar diferentes versiones de UUID. (Los UUID de la versión 2 no se especifican en RFC 4122 y no están soportados por este módulo)

      >>> import uuid
      >>> # make a UUID based on the host ID and current time
      >>> uuid.uuid1()
      UUID('a8098c1a-f86e-11da-bd1a-00112444be1e')

      >>> # make a UUID using an MD5 hash of a namespace UUID and a name
      >>> uuid.uuid3(uuid.NAMESPACE_DNS, 'python.org')
      UUID('6fa459ea-ee8a-3ca4-894e-db77e160355e')

      >>> # make a random UUID
      >>> uuid.uuid4()
      UUID('16fd2706-8baf-433b-82eb-8c7fada847da')

      >>> # make a UUID using a SHA-1 hash of a namespace UUID and a name
      >>> uuid.uuid5(uuid.NAMESPACE_DNS, 'python.org')
      UUID('886313e1-3b8a-5372-9b90-0c9aee199e5d')

  (Contribución de Ka-Ping Yee.)

- Los tipos `weakref` del módulo `WeakKeyDictionary` y `WeakValueDictionary` han obtenido nuevos métodos para iterar sobre las referencias débiles contenidas en el diccionario. Se han añadido los métodos `iterkeyrefs()` y `keyrefs()` a `WeakKeyDictionary`, y `itervaluerefs()` y `valuerefs()` a `WeakValueDictionary`. (Contribución de Fred L. Drake, Jr.)

- El módulo `webbrowser` ha recibido una serie de mejoras. Ahora se puede utilizar como un script con `python -m webbrowser`, tomando una URL como argumento; hay una serie de interruptores para controlar el comportamiento (`-n` para una nueva ventana del navegador, `-t` para una nueva pestaña). Se han añadido nuevas funciones a nivel de módulo, `open_new()` y `open_new_tab()`, para soportar esto. La función `open()` del módulo soporta una característica adicional, un parámetro autoraise que señala si se debe levantar la ventana abierta cuando sea posible. Se añadieron varios navegadores adicionales a la lista de soportados, como Firefox, Opera, Konqueror y elinks. (Contribución de Oleg Broytmann y Georg Brandl)

- El módulo `xmlrpclib` ahora soporta la devolución de objetos `datetime` para el tipo de fecha XML-RPC. Proporcione `use_datetime=True` a la función `loads()` o a la clase `Unmarshaller` para activar esta característica. (Contribución de Skip Montanaro)

- El módulo `zipfile` ahora soporta la versión ZIP64 del formato, lo que significa que un archivo .zip ahora puede ser mayor de 4 GiB y puede contener archivos individuales mayores de 4 GiB. (Contribución de Ronald Oussoren)

- Los objetos `zlib` y `Decompress` del módulo `zlib` soportan ahora un método `copy()` que realiza una copia del estado interno del objeto y devuelve un nuevo objeto `Compress` o `Decompress`. (Contribución de Chris AtLee)

### El paquete ctypes

El paquete `ctypes`, escrito por Thomas Heller, se ha añadido a la biblioteca estándar. `ctypes` permite llamar a funciones arbitrarias en bibliotecas compartidas o DLL. Los usuarios veteranos recordarán el módulo `dl`, que proporciona funciones para cargar bibliotecas compartidas y llamar a las funciones que contienen. El paquete `ctypes` es mucho más sofisticado.

Para cargar una biblioteca compartida o DLL, debes crear una instancia de la clase `CDLL` y proporcionar el nombre o la ruta de la biblioteca compartida o DLL. Una vez hecho esto, puedes llamar a funciones arbitrarias accediendo a ellas como atributos del objeto `CDLL`.

    import ctypes

    libc = ctypes.CDLL('libc.so.6')
    result = libc.printf("Line of output\n")

Se proporcionan constructores de tipos para los distintos tipos de C: `c_int()`, `c_float()`, `c_double()`, `c_char_p()` (equivalente a char*), etc. A diferencia de los tipos de Python, las versiones de C son todas mutables; puedes asignar a su atributo `value` para cambiar el valor envuelto. Los enteros y las cadenas de Python se convertirán automáticamente a los tipos C correspondientes, pero para otros tipos debes llamar al constructor de tipo correcto. (Y quiero decir debe; si se equivoca, a menudo el intérprete se bloquea con un fallo de segmentación)

No debería usar `c_char_p()` con una cadena de Python cuando la función C vaya a modificar el área de memoria, porque se supone que las cadenas de Python son inmutables; romper esta regla causará errores desconcertantes. Cuando necesite un área de memoria modificable, utilice `create_string_buffer()`:

    s = "this is a string"
    buf = ctypes.create_string_buffer(s)
    libc.strfry(buf)

Se supone que las funciones en C devuelven números enteros, pero se puede establecer el atributo `restype` del objeto de la función para cambiar esto:

    >>> libc.atof('2.71828')
    -1783957616
    >>> libc.atof.restype = ctypes.c_double
    >>> libc.atof('2.71828')
    2.71828

`ctypes` también proporciona una envoltura para la API de C de Python como el objeto `ctypes.pythonapi`. Este objeto no libera el bloqueo global del intérprete antes de llamar a una función, porque el bloqueo debe mantenerse cuando se llama al código del intérprete. Hay un constructor de tipo `py_object()` que creará un puntero PyObject*. Un uso sencillo:

    import ctypes

    d = {}
    ctypes.pythonapi.PyObject_SetItem(ctypes.py_object(d),
              ctypes.py_object("abc"),  ctypes.py_object(1))
    # d is now {'abc', 1}.

No olvides usar `py_object()`; si se omite acabas con un fallo de segmentación.

`ctypes` existe desde hace tiempo, pero la gente sigue escribiendo y distribuyendo módulos de extensión codificados a mano porque no se puede confiar en que `ctypes` esté presente. Quizás los desarrolladores empiecen a escribir envoltorios de Python sobre una biblioteca a la que se accede a través de `ctypes` en lugar de módulos de extensión, ahora que `ctypes` está incluido en el núcleo de Python.

Ver también

https://web.archive.org/web/20180410025338/http://starship.python.net/crew/theller/ctypes/

  The pre-stdlib ctypes web page, with a tutorial, reference, and FAQ.

La documentación del módulo `ctypes`.

### El paquete ElementTree

Un subconjunto de la biblioteca ElementTree de Fredrik Lundh para el procesamiento de XML se ha añadido a la biblioteca estándar como `xml.etree`. Los módulos disponibles son `ElementTree`, `ElementPath` y `ElementInclude` de ElementTree 1.2.6. También se incluye el módulo acelerador `cElementTree`.

The rest of this section will provide a brief overview of using ElementTree. Full documentation for ElementTree is available at https://web.archive.org/web/20201124024954/http://effbot.org/zone/element-index.htm.

ElementTree representa un documento XML como un árbol de nodos de elementos. El contenido de texto del documento se almacena como los atributos `text` y `tail` de (Esta es una de las principales diferencias entre ElementTree y el Modelo de Objetos del Documento; en el DOM hay muchos tipos diferentes de nodo, incluyendo `TextNode`)

La función de análisis más utilizada es `parse()`, que toma una cadena (se supone que contiene un nombre de archivo) o un objeto similar a un archivo y devuelve una instancia de `ElementTree`:

    from xml.etree import ElementTree as ET

    tree = ET.parse('ex-1.xml')

    feed = urllib.urlopen(
              'http://planet.python.org/rss10.xml')
    tree = ET.parse(feed)

Una vez que tengas una instancia de `ElementTree`, puedes llamar a su método `getroot()` para obtener el nodo raíz de `Element`.

También hay una función `XML()` que toma un literal de cadena y devuelve un nodo `Element` (no un `ElementTree`). Esta función proporciona una forma ordenada de incorporar fragmentos XML, acercándose a la comodidad de un literal XML:

    svg = ET.XML("""<svg width="10px" version="1.0">
                 </svg>""")
    svg.set('height', '320px')
    svg.append(elem1)

Cada elemento XML admite algunos métodos de acceso tipo diccionario y otros tipo lista. Las operaciones tipo diccionario se utilizan para acceder a los valores de los atributos, y las operaciones tipo lista se utilizan para acceder a los nodos hijos.

Operación | Resultado
--- | ---
`elem[n]` | Devuelve el elemento hijo enésimo.
`elem[m:n]` | Devuelve la lista de m’s a n’s elementos hijos.
`len(elem)` | Devuelve el número de elementos hijos.
`lista(elem)` | Devuelve la lista de elementos hijos.
`elem.append(elem2)` | Añade elemento2 como hijo.
`elem.insert(index, elem2)` | Inserta elemento2 en el lugar especificado.
`del elem[n]` | Elimina el elemento hijo enésimo.
`elem.keys()` | Devuelve la lista de nombres de atributos.
`elem.get(name)` | Devuelve el valor del atributo nombre.
`elem.set(nombre, valor)` | Establece el nuevo valor del atributo nombre.
`elem.attrib` | Recupera el diccionario que contiene los atributos.
`del elem.attrib[name]` | Borra el atributo nombre.

Los comentarios y las instrucciones de procesamiento también se representan como nodos `Element`. Para comprobar si un nodo es un comentario o unas instrucciones de procesamiento:

    if elem.tag is ET.Comment:
        ...
    elif elem.tag is ET.ProcessingInstruction:
        ...

Para generar una salida XML, debes llamar al método `ElementTree.write()`. Al igual que `parse()`, puede tomar una cadena o un objeto tipo archivo:

    # Encoding is US-ASCII
    tree.write('output.xml')

    # Encoding is UTF-8
    f = open('output.xml', 'w')
    tree.write(f, encoding='utf-8')

(Atención: la codificación por defecto utilizada para la salida es ASCII. Para el trabajo general de XML, donde el nombre de un elemento puede contener caracteres Unicode arbitrarios, ASCII no es una codificación muy útil porque lanzará una excepción si el nombre de un elemento contiene cualquier carácter con valores superiores a 127. Por lo tanto, es mejor especificar una codificación diferente, como UTF-8, que puede manejar cualquier carácter Unicode)

Esta sección es sólo una descripción parcial de las interfaces de ElementTree. Por favor, lee la documentación oficial del paquete para más detalles.

Ver también

https://web.archive.org/web/20201124024954/http://effbot.org/zone/element-index.htm

  Documentación oficial de ElementTree.

### El paquete hashlib

Se ha añadido un nuevo módulo `hashlib`, escrito por Gregory P. Smith, para sustituir a los módulos `md5` y `sha`. `hashlib` añade soporte para hashes seguros adicionales (SHA-224, SHA-256, SHA-384 y SHA-512). Cuando está disponible, el módulo utiliza OpenSSL para implementaciones rápidas de algoritmos optimizados para la plataforma.

Los antiguos módulos `md5` y `sha` siguen existiendo como envoltorios de hashlib para preservar la compatibilidad hacia atrás. La interfaz del nuevo módulo es muy parecida a la de los módulos antiguos, pero no es idéntica. La diferencia más significativa es que las funciones constructoras para crear nuevos objetos hashing tienen un nombre diferente

    # Old versions
    h = md5.md5()
    h = md5.new()

    # New version
    h = hashlib.md5()

    # Old versions
    h = sha.sha()
    h = sha.new()

    # New version
    h = hashlib.sha1()

    # Hash that weren't previously available
    h = hashlib.sha224()
    h = hashlib.sha256()
    h = hashlib.sha384()
    h = hashlib.sha512()

    # Alternative form
    h = hashlib.new('md5')          # Provide algorithm as a string

Una vez que se ha creado un objeto hash, sus métodos son los mismos que antes: `actualizar(cadena)` convierte la cadena especificada en el estado de resumen actual, `digest()` y `hexdigest()` devuelven el valor de resumen como una cadena binaria o una cadena de dígitos hexadecimales, y `copiar()` devuelve un nuevo objeto hash con el mismo estado de resumen.

Ver también

La documentación del módulo `hashlib`.

### El paquete sqlite3

El módulo pysqlite (http://www.pysqlite.org), una envoltura para la base de datos incrustada SQLite, se ha añadido a la biblioteca estándar bajo el nombre de paquete `sqlite3`.

SQLite es una biblioteca en C que proporciona una base de datos ligera basada en disco que no requiere un proceso de servidor independiente y permite acceder a la base de datos utilizando una variante no estándar del lenguaje de consulta SQL. Algunas aplicaciones pueden utilizar SQLite para el almacenamiento interno de datos. También es posible crear un prototipo de una aplicación utilizando SQLite y luego portar el código a una base de datos más grande como PostgreSQL u Oracle.

pysqlite fue escrito por Gerhard Häring y proporciona una interfaz SQL que cumple con la especificación DB-API 2.0 descrita por PEP 249.

Si estás compilando el código fuente de Python tú mismo, ten en cuenta que el árbol de código fuente no incluye el código de SQLite, sólo el módulo envolvente. Necesitarás tener las librerías y cabeceras de SQLite instaladas antes de compilar Python, y el proceso de construcción compilará el módulo cuando las cabeceras necesarias estén disponibles.

Para utilizar el módulo, primero hay que crear un objeto `Connection` que represente la base de datos. Aquí los datos se almacenarán en el archivo `/tmp/example`:

    conn = sqlite3.connect('/tmp/example')

También puede suministrar el nombre especial `:memory:` para crear una base de datos en la RAM.

Una vez que tengas una `Connection`, puedes crear un objeto `Cursor` y llamar a su método `execute()` para realizar comandos SQL:

    c = conn.cursor()

    # Create table
    c.execute('''create table stocks
    (date text, trans text, symbol text,
     qty real, price real)''')

    # Insert a row of data
    c.execute("""insert into stocks
              values ('2006-01-05','BUY','RHAT',100,35.14)""")

Normalmente tus operaciones SQL necesitarán usar valores de variables de Python. No deberías montar tu consulta usando las operaciones de cadena de Python porque hacerlo es inseguro; hace que tu programa sea vulnerable a un ataque de inyección SQL.

En su lugar, utilice la sustitución de parámetros de la DB-API. Ponga `?` como marcador de posición donde quiera usar un valor, y luego proporcione una tupla de valores como segundo argumento al método `execute()` del cursor. (Otros módulos de base de datos pueden utilizar un marcador de posición diferente, como `%s` o `:1`) Por ejemplo:

    # Never do this -- insecure!
    symbol = 'IBM'
    c.execute("... where symbol = '%s'" % symbol)

    # Do this instead
    t = (symbol,)
    c.execute('select * from stocks where symbol=?', t)

    # Larger example
    for t in (('2006-03-28', 'BUY', 'IBM', 1000, 45.00),
              ('2006-04-05', 'BUY', 'MSOFT', 1000, 72.00),
              ('2006-04-06', 'SELL', 'IBM', 500, 53.00),
             ):
        c.execute('insert into stocks values (?,?,?,?,?)', t)

Para recuperar datos después de ejecutar una sentencia SELECT, puede tratar el cursor como un iterador, llamar al método `fetchone()` del cursor para recuperar una sola fila que coincida, o llamar a `fetchall()` para obtener una lista de las filas que coincidan.

Este ejemplo utiliza la forma del iterador:

    >>> c = conn.cursor()
    >>> c.execute('select * from stocks order by price')
    >>> for row in c:
    ...    print row
    ...
    (u'2006-01-05', u'BUY', u'RHAT', 100, 35.140000000000001)
    (u'2006-03-28', u'BUY', u'IBM', 1000, 45.0)
    (u'2006-04-06', u'SELL', u'IBM', 500, 53.0)
    (u'2006-04-05', u'BUY', u'MSOFT', 1000, 72.0)
    >>>

Para más información sobre el dialecto SQL soportado por SQLite, consulte https://www.sqlite.org.

Ver también

http://www.pysqlite.org

  La página web de pysqlite.

https://www.sqlite.org

  La página web de SQLite; la documentación describe la sintaxis y los tipos de datos disponibles para el dialecto SQL soportado.

La documentación del módulo `sqlite3`.

PEP 249 - Especificación de la API de la base de datos 2.0

  PEP escrito por Marc-André Lemburg.

### El paquete wsgiref

La Interfaz de Pasarela del Servidor Web (WSGI) v1.0 define una interfaz estándar entre los servidores web y las aplicaciones web de Python y se describe en PEP 333. El paquete `wsgiref` es una implementación de referencia de la especificación WSGI.

El paquete incluye un servidor HTTP básico que ejecutará una aplicación WSGI; este servidor es útil para la depuración pero no está pensado para su uso en producción. La configuración de un servidor sólo requiere unas pocas líneas de código:

    from wsgiref import simple_server

    wsgi_app = ...

    host = ''
    port = 8000
    httpd = simple_server.make_server(host, port, wsgi_app)
    httpd.serve_forever()

Ver también

https://web.archive.org/web/20160331090247/http://wsgi.readthedocs.org/en/latest/

  Un sitio web central para los recursos relacionados con WSGI.

PEP 333 - Interfaz del servidor web Python v1.0

  PEP escrito por Phillip J. Eby.

## Cambios en la API de construcción y C

Los cambios en el proceso de construcción de Python y en la API de C incluyen:

- El árbol de fuentes de Python fue convertido de CVS a Subversion, en un complejo procedimiento de migración que fue supervisado y llevado a cabo de forma impecable por Martin von Löwis. El procedimiento se desarrolló como PEP 347.

- Coverity, una empresa que comercializa una herramienta de análisis de código fuente llamada Prevent, proporcionó los resultados de su examen del código fuente de Python. El análisis encontró alrededor de 60 errores que fueron rápidamente corregidos. Muchos de los errores eran problemas de recuento, que a menudo se producen en el código de gestión de errores. Consulte las estadísticas en https://scan.coverity.com.

- El mayor cambio en la API de C proviene de PEP 353, que modifica el intérprete para utilizar una definición de tipo `Py_ssize_t` en lugar de int. Vea la sección anterior PEP 353: Uso de ssize_t como tipo de índice para una discusión de este cambio.

- El diseño del compilador de código de bytes ha cambiado mucho, ya no genera código de bytes recorriendo el árbol de análisis sintáctico. En su lugar, el árbol de análisis se convierte en un árbol de sintaxis abstracta (o AST), y es el árbol de sintaxis abstracta el que se recorre para producir el código de bytes.

  Es posible que el código Python obtenga objetos AST utilizando el built-in `compile()` y especificando `_ast.PyCF_ONLY_AST` como valor del parámetro flags:

      from _ast import PyCF_ONLY_AST
      ast = compile("""a=0
      for i in range(10):
          a += i
      """, "<string>", 'exec', PyCF_ONLY_AST)

      assignment = ast.body[0]
      for_loop = ast.body[1]

  Todavía no se ha escrito ninguna documentación oficial para el código AST, pero PEP 339 discute el diseño. Para empezar a conocer el código, lea la definición de los distintos nodos AST en `Parser/Python.asdl`. Un script de Python lee este archivo y genera un conjunto de definiciones de estructuras C en `Include/Python-ast.h`. Las funciones `PyParser_ASTFromString()` y `PyParser_ASTFromFile()`, definidas en `Include/pythonrun.h`, toman el código fuente de Python como entrada y devuelven la raíz de un AST que representa el contenido. Este AST puede convertirse en un objeto de código mediante `PyAST_Compile()`. Para más información, lea el código fuente, y luego haga preguntas en python-dev.

  El código de la AST fue desarrollado bajo la dirección de Jeremy Hylton, e implementado por (en orden alfabético) Brett Cannon, Nick Coghlan, Grant Edwards, John Ehresman, Kurt Kaiser, Neal Norwitz, Tim Peters, Armin Rigo y Neil Schemenauer, además de los participantes en varios sprints de la AST en conferencias como la PyCon.

- Se aplicó el parche de Evan Jones a obmalloc, descrito por primera vez en una charla en la PyCon DC 2005. Python 2.4 asignaba objetos pequeños en arenas de 256K, pero nunca liberaba arenas. Con este parche, Python liberará arenas cuando estén vacías. El efecto neto es que en algunas plataformas, cuando se asignan muchos objetos, el uso de la memoria de Python puede realmente caer cuando se borran y la memoria puede ser devuelta al sistema operativo. (Implementado por Evan Jones, y reelaborado por Tim Peters)

  Tenga en cuenta que este cambio significa que los módulos de extensión deben ser más cuidadosos al asignar memoria. La API de Python tiene muchas funciones diferentes para asignar memoria que se agrupan en familias. Por ejemplo, `PyMem_Malloc()`, `PyMem_Realloc()`, y `PyMem_Free()` son una familia que asigna memoria en bruto, mientras que `PyObject_Malloc()`, `PyObject_Realloc()`, y `PyObject_Free()` son otra familia que se supone que se utiliza para crear objetos de Python.

  Anteriormente estas diferentes familias se reducían a las funciones `malloc()` y `free()` de la plataforma. Esto significaba que no importaba si te equivocabas y asignabas memoria con la función `PyMem()` pero la liberabas con la función `PyObject()`. Con los cambios de la versión 2.5 en obmalloc, estas familias hacen ahora cosas diferentes y los desajustes probablemente darán lugar a un fallo de seguridad. Deberías probar cuidadosamente tus módulos de extensión C con Python 2.5.

- Los tipos de conjuntos incorporados tienen ahora una API oficial en C. Llame a `PySet_New()` y `PyFrozenSet_New()` para crear un nuevo conjunto, `PySet_Add()` y `PySet_Discard()` para añadir y eliminar elementos, y `PySet_Contains()` y `PySet_Size()` para examinar el estado del conjunto. (Contribución de Raymond Hettinger)

- El código C puede ahora obtener información sobre la revisión exacta del intérprete de Python llamando a la función `Py_GetBuildInfo()` que devuelve una cadena de información de compilación como esta `"trunk:45355:45356M, Apr 13 2006, 07:42:19"`. (Contribuido por Barry Warsaw.)

- Se pueden utilizar dos nuevas macros para indicar las funciones C que son locales al fichero actual, de modo que se pueda utilizar una convención de llamada más rápida. `Py_LOCAL(type)` declara que la función devuelve un valor del tipo especificado y utiliza un calificador de llamada rápida. `Py_LOCAL_INLINE(type)` hace lo mismo y también solicita que la función sea inline. Si `PY_LOCAL_AGGRESSIVE()` se define antes de que se incluya `python.h`, se habilita un conjunto de optimizaciones más agresivas para el módulo; debería comparar los resultados para averiguar si estas optimizaciones realmente hacen el código más rápido. (Contribuido por Fredrik Lundh en el sprint NeedForSpeed)

- `PyErr_NewException(name, base, dict)` ahora puede aceptar una tupla de clases base como su argumento base. (Contribuido por Georg Brandl.)

- La función `PyErr_Warn()` para emitir avisos está ahora obsoleta en favor de `PyErr_WarnEx(category, message, stacklevel)` que permite especificar el número de marcos de pila que separan esta función y la que la llama. Un stacklevel de 1 es la función que llama a `PyErr_WarnEx()`, 2 es la función que está por encima, y así sucesivamente. (Añadido por Neal Norwitz.)

- El intérprete de CPython sigue estando escrito en C, pero el código ahora puede ser compilado con un compilador de C++ sin errores. (Implementado por Anthony Baxter, Martin von Löwis, Skip Montanaro)

- Se ha eliminado la función `PyRange_New()`. Nunca se documentó, nunca se utilizó en el código del núcleo, y tenía una comprobación de errores peligrosamente laxa. En el improbable caso de que sus extensiones la utilizaran, puede sustituirla por algo como lo siguiente:

      range = PyObject_CallFunction((PyObject*) &PyRange_Type, "lll",
                                    start, stop, step);

### Cambios específicos en los puertos

- MacOS X (10.3 y superior): la carga dinámica de módulos utiliza ahora la función `dlopen()` en lugar de funciones específicas de MacOS.

- MacOS X: se ha añadido una opción `--enable-universalsdk` al script configure que compila el intérprete como un binario universal capaz de funcionar tanto en procesadores PowerPC como Intel. (Contribución de Ronald Oussoren; bpo-2573.)

- Windows: `.dll` ya no se admite como extensión de nombre de archivo para los módulos de extensión. `.pyd` es ahora la única extensión de nombre de archivo que se buscará.

## Adaptación a Python 2.5

Esta sección enumera los cambios descritos anteriormente que pueden requerir cambios en su código:

- ASCII es ahora la codificación por defecto para los módulos. Ahora es un error de sintaxis si un módulo contiene literales de cadena con caracteres de 8 bits pero no tiene una declaración de codificación. En Python 2.4 esto provocaba una advertencia, no un error de sintaxis.

- Anteriormente, el atributo `gi_frame` de un generador era siempre un objeto frame. Debido a los cambios de PEP 342 descritos en la sección PEP 342: Nuevas funciones del generador, ahora es posible que `gi_frame` sea `None`.

- Una nueva advertencia, `UnicodeWarning`, se lanza cuando se intenta comparar una cadena Unicode y una cadena de 8 bits que no puede ser convertida a Unicode utilizando la codificación ASCII por defecto. Anteriormente estas comparaciones lanzaban una excepción `UnicodeDecodeError`.

- Biblioteca: el módulo `csv` es ahora más estricto con los campos citados en varias líneas. Si sus archivos contienen nuevas líneas incrustadas dentro de los campos, la entrada debe dividirse en líneas de manera que se conserven los caracteres de nueva línea.

- Biblioteca: la función `format()` del módulo `locale` aceptaba antes cualquier cadena siempre que no apareciera más de un especificador %char. En Python 2.5, el argumento debe ser exactamente un especificador %char sin texto alrededor.

- Biblioteca: Los módulos `pickle` y `cPickle` ya no aceptan un valor de retorno de `None` del método `__reduce__()`; el método debe devolver una tupla de argumentos. Los módulos tampoco aceptan ya el parámetro obsoleto de la palabra clave bin.

- Biblioteca: Las clases `SimpleXMLRPCServer` y `DocXMLRPCServer` tienen ahora un atributo `rpc_paths` que restringe las operaciones XML-RPC a un conjunto limitado de rutas URL; por defecto sólo se permiten `'/'` y `'/RPC2'`. Establecer `rpc_paths` como `None` o una tupla vacía desactiva esta comprobación de rutas.

- API C: Muchas funciones utilizan ahora `Py_ssize_t` en lugar de int para permitir el procesamiento de más datos en máquinas de 64 bits. Es posible que el código de las extensiones tenga que hacer el mismo cambio para evitar advertencias y soportar máquinas de 64 bits. Véase la sección anterior PEP 353: Uso de ssize_t como tipo de índice para una discusión de este cambio.

- C API: Los cambios en obmalloc significan que debe tener cuidado de no mezclar el uso de las familias de funciones PyMem_* y PyObject_*. La memoria asignada con la función *_Malloc de una familia debe ser liberada con la función *_Free de la familia correspondiente.

## Agradecimientos

El autor desea agradecer a las siguientes personas sus sugerencias, correcciones y ayuda en varios borradores de este artículo: Georg Brandl, Nick Coghlan, Phillip J. Eby, Lars Gustäbel, Raymond Hettinger, Ralf W. Grosse-Kunstleve, Kent Johnson, Iain Lowe, Martin von Löwis, Fredrik Lundh, Andrew McNamara, Skip Montanaro, Gustavo Niemeyer, Paul Prescod, James Pryor, Mike Rovner, Scott Weikart, Barry Warsaw, Thomas Wouters.