Los detalles de esta ampliación están en el PEP 341. Antes de la versión 2.5, las sentencias try venian en dos sabores:

• Se podía usar una sentencia finally para garantizar que un determinado código se ejecutaba en cualquier circustancia (Por ejemplo, para asegurarse de que un fichero abierto se cierra a pesar de cualquier error en el código)


• O bien se podián usar una o más sentencias except para atrapar excepciones específicas.

No se podían combinar los dos usos, es decir, no se podían usar simultaneamente sentencias except con una finally, porque la generación de código correcto para esta combinación era muy complicada, y no estaba claro el significado exacto que debía tener la combinación.

Nuestro Benevolente Dictador Vitalicio, Guido van Rossum, invirtió parte de su tiempo en trabajar con Java, que sí soportaba el equivalente de una combinación de excepts y finally en un único bloque, y esto aclaró la cuestión de cual debía ser el significado de la sentencia. En Python 2.5 se puede escribir ahora:

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

El significado es este: Se ejecuta el código en el bloque block-1. Si se produce algúna excepción durante su ejecución, se recorren las diferentes bloques de excepts, buscando alguno que case con la excepción producida. Por ejemplo, si se produce una excepción del tipo Exception2, se ejecutará el código del bloque handler-2. Si no se ha producido ninguna excepción, se ejecutará tambien el código de la sentencia else —en nuestro caso else-block— si estuviera presente.

Sea cual sea el resultado hasta ahora, el código en la sentencia final es ejecutado, una vez que todo el código anterior (incluyendo el código encargado de gestionar las excepciones producidas) haya sido ejecutado. Incluso en el caso de que hubiera un error en el manejador de la excepción o en el bloque else y se produzca una nueva excepción, el código en la sentencia final siempre se ejecutará.

---

Más información sobre las novedades en Python 2.5

Pues eso, que ya está disponible la versión final de Python 2.5. Todo el mundo a bajársela de la página oficial de Python 2.5. Ya sería posible su uso en entornos de producción.

Para el que esté interesado, recordar que hay una serie de entradas en este blog, detallando las novedades incorporadas en esta nueva versión respecto a la 2.4, todas ellas con un título precedido por la etiqueta [Python 2.5]. Las entradas están basadas en What's new in Python 2.5.

A ver si los de Blogger me pasan de una p*ñ*t*r* vez a la nueva versión y puedo usar tags como Doraemon manda.

Estas mejoras son resultado de la implantación de la PEP 338. Este documento describe la sintaxis a utilizar para ejecutar un módulo como si fuera un programa, usando o bien la opción de línea de comando -m o llamando a la función runpy.run_module(modulename).

La posibilidad de usar -m se añadió en Python 2.4, y se ha ampliado en la versión 2.5. En vez de estar implementada en C dentro del interprete Python, se utiliza la implementación incluido en un nuevo módulo de la librería estándar, runpy.

Este nuevo módulo usa un sistema mucho más sofisticado para realizar las importaciones, de forma que ahora resulta posible ejecutar módulos que están dentro de un paquete, como pychecker.checker (pychecker es una herramienta que comprueba equivocaciones habituales de programación, similar al lint de C).

El módulo permite también usar mecanismos alternativos de importación, como por ejemplo el módulo zipimport. De esta forma, ahora será posible añadir un fichero .zip al sys.path y luego utilizar la opción -m para ejecutar el código dentro del archivo.

---

Más información sobre las novedades en Python 2.5

En Python 2.5 se ha implementado la totalidad de las mejoras realizadas en la propuesta PEP 328 (PEP significa Python Enhancement Proposals, es la forma de dirigir y planificar el desarrollo futuro del lenguaje).

Las partes más fáciles ya fueron implementadas en Python 2.4. La parte del león es la que se implementa en Python 2.5: Poder importar un módulo utilizando referencias relativas.

Para entender el nuevo método de importación, veamos cómo funciona la cosa en la actualidad: supongamos un directorio con la siguiente estructura:

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

Esta estructura define un paquete llamado pkg, el cual contiene los submódulos pkg.main y pkg.string.

Consideremos el código del módulo main.py. ¿Qué pasa si ejecuta la sentencia import string? En Python 2.4 y versiones anteriores, se realizará una búsqueda en el directorio del paquete, encontrará el módulo pkg/string.py, y lo importará en el espacio de nombres de main con el nombre string.

Todo perfecto, si es que era ese el módulo que queríamos importar, pero ¿qué pasa si en realidad queríamos acceder al módulo string estándar de python? No existía una manera limpia de evitar la búsqueda en el directorio del paquete; la forma habitual pasaba por modificar el contenido de la variable sysmodules, algo que difícilmente puede considerarse limpio, no digamos ya elegante.

La lectura del código que dependía de imports relativos tampoco es demasiado clara, porque no queda claro cuál es el código que realmente se está utilizando, el módulo string estándar o el pkg.string. El programador avispado aprende rápidamente a evitar usar los nombres de los módulos de la librería estándar, pero siempre existiría el riesgo de conflictos con los módulos que se añadan en el futuro.

Para evitar estos problemas, la importación absoluta se convertirá en un futuro cercano -quizás en Python 2.7- en la opción por omisión. A partir de ese momento, la sentencia import string siempre cargará el paquete string estándar. Se recomienda a los usuarios que empiecen a usar los imports absolutos siempre que sea posible; es decir, que para importar nuestro propio módulo string en el ejemplo anterior, es preferible hacerlo escribiendo from pkg import string. En Python 2.5, podemos especificar que queremos utilizar por defecto la importación absoluta, utilizando la sentencia from __future__ import absolute_import.

Las importaciones relativas siguen siendo posibles, añadiendo para ello un punto que preceda al nombre del módulo a importar, como en el siguiente ejemplo:

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

Se pueden usar puntos adicionales para indicar rutas relativas desde el directorio padre del paquete actual. Por ejemplo, es posible, para el código que reside en el módulo A.B.C, realizar las siguientes importaciones:

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

El uso de estos puntos prefijos en la sentencia import solo se permite utilizar en la forma from ... import X, no es posible usarlo en un import directo.

---

Más información sobre las novedades en Python 2.5

El modulo distutils se introdujo en la versión 2.0, y su propósito era simplificar la vida tanto al desarrollador de nuevos módulos, que dispondría de un sistema sencillo y estándar para distribuir su código, como al usuario final, que podría instalarlos de forma sencilla. Posteriormente, el uso de un sistema común ha permitido la creación de un repositorio público y común de módulos para Python (Similar, pero en algunos aspectos diferente, del CPAN de PERL). El repositorio tiene el nombre de PyPI archive, abreviatura de Python Package Index. También es conocido como la tienda de queso de python, nombre tomado de un sketch de los Monty Python. Que te gusten los Monty Python no es obligatorio para programar en Python, pero ayuda.


La principal novedad en el módulo distutils es la posibilidad de usar un sencillo sistema de dependencias. La función setup() tienen ahora tres parámetros opcionales, cuyos nombres son requires, provides y obsoletes. A la hora de empaquetar una distribución de código fuente con el comando sdist, la información sobre dependencias se incorporará automáticamente en el fichero PKG-INFO.

Existe un cuarto parámetro opcional, cuyo nombre es download_url, que sirve para indicar la localización en Internet del código fuente del paquete. De esta forma se podrá determinar las dependencias de un paquete y descargar el resto de 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 novedad en la tienda de queso (cheeseshop.python.org) es la capacidad de almacenar el código tanto en forma binaria como en código fuente. El nuevo comando upload permite también subir un nuevo paquete al repositorio. El paquete se puede firmar digitalmente, con GPG, usando las opciones --sign y --identity

---

Más información sobre las novedades en Python 2.5