http://www.python.org/download/releases/2.5/
 
Points d'intérêt:
 
PEP 341 - TRY/CATCH/FINALLY
Jusqu'ici, on pouvait utiliser soit try/except (pour catcher les erreurs) soit try/finally (pour avoir un bloc toujours exécuté).
 
Contrairement à Java, il n'était par contre pas possible d'avoir try/catch/finally dans le même bloc (l'idiôme consistait en l'utilisation d'un try/except à l'intérieur d'un try/finally)
 
Avec Python 2.5 ont peut maintenant avoir un vrai bloc try/except/finally sans aucun problème
 
Exemple:
Python 2.4

try:
    try:
        int("erreur" )
    except ValueError, e:
        print "Erreur %s"%(e)
finally:
    print "Ce bloc est toujours exécuté"

 
Python 2.5:

try:
    int("erreur" )
except ValueError, e:
    print "Erreur %s"%(e)
finally:
    print "Ce bloc est toujours exécuté"

Pas un gain terrifiant, mais une simplification et une clarification notable du code
 
PEP 308 - Conditional Expressions
 
L'"opérateur ternaire" des dérivés du C (query?true_exp:false_exp) a maintenant un équivalent Python.
 
La syntaxe choisie par le BDFL est la suivante:

x = true_value if condition else false_value

Cette syntaxe à première vue étrange a été choisie en essayant de l'appliquer dans la module de la stdlib et en en observant la lisibilité:

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

À noter qu'il est possible d'entourer cette expression avec des parenthèse, et qu'il est conseillé de le faire pour des raisons de style et de clarté, ainsi que pour éviter certains cas syntaxique ambigu (principalement lors de l'utilisation de lambdas).
 
Utiliser, donc,

x = (true_value if condition else false_value)

 
PEP 309 - Partial Function Application (currying)
 
Les utilisateurs de langages fonctionnels (à la Haskell) connaissent déjà cet usage, consistant à appeler une fonction avec moins de paramètre que nécessaires, et à récupérer une fonction auxquels ces arguments ont été pré-appliqués (d'où le nom d'application partielle).
 
La fonction `partial` du module `functools`* permet exactement cet usage:
 

>>> def adder(x,y): return x+y
 
>>> f0 = functools.partial(adder, 3, 8)
>>> f0()
11
 
>>> add5 = functools.partial(adder, 5)
>>> add5(3)
8

(*): functools est un nouveau module dédié aux constructs fonctionnels qui apparaîtront dans Python dans le futur. Actuellement, il contient également une fonction update_wrapper et une fonction wraps ayant pour but de simplifier la création de décorateurs)
 
PEP 328 - imports absolus et relatifs
 
Pas trop regardé, pas encore compris.
 
Ce comportement est de toute façon optionnel (from __future__ import absolute_import) actuellement.
Il deviendra le défaut dans une version future (probablement Python 2.7), je vous conseille donc tout de même de le comprendre.
 
PEP 338 - Exécuter un module en tant que script
 
Amélioration du switch -m
 
PEP 342 - Nouvelles fonctionalités des générateurs
 

• Il est maitenant possible d'envoyer une valeur à un générateur en utilisant la méthode `send`
• Yield a été modifiée pour renvoyer une valeur. Cette valeur est celle qui a été envoyée via `send`. Si aucune valeur n'a été envoyée, yield retourne None. Pour des raisons de style, vous êtes priés d'entourer une expression `yield` de parenthèses quand vous en récupérez une valeur.
• La méthode `throw` force le générateur à lancer une exception (qui doit être fournie en paramètre à throw)
• `close` force le générateur à se terminer en envoyant `GeneratorExit` (depuis le du yield). Le générateur doit impérativement "mourir" en throwant GeneratorExit ou StopIteration. Catcher l'exception sans rethrower immédiatement GeneratorExit ou StopIteration est illégal et génèrera une RuntimeError.

PEP 352 - Exceptions en tant que new-style classes
 
La hiérarchie des exceptions built-in démarre maintenant à BaseException, dont héritent KeyboardInterrupt, SystemExit et Exception, elle même racine pour toutes les exceptions du système. Il est également déprécié de thrower une chaîne de caractère, et un warning sera à présent généré.
 
Ceci permet à présent de catcher toutes les exceptions sauf KeyboardInterrupt et SystemExit (qui devraient être relancées en permanence) en utilisant simplement `except Exception` au lieu d'un simple `except`. Dans le futur, toutes les exceptions throwées devront hériter de BaseException ou ses descendants (e.g. Exception), au maximum pour Python 3.0 et probablement bien avant. Il est donc conseillé de commencer dès maintenant à faire hériter vos exceptions d'Exception ou BaseException.
 
PEP 353 - ssize_t
 
Les index python sont maintenant implémentés en utilisant ssize_t, ce qui permet d'augmenter drastiquement les capacités des conteneurs Python sur les plateformes 64bits (aucun changement en 32b)
 
PEP 357 - __index__ et slices
 
NumPy définissant des types entiers signés et non signés sur 8, 16, 32 et 64bits, il était intéressant de pouvoir utiliser ces types comme index de slices (entre autres). Aucun moyen de le faire n'existant et les slices ne pouvant utiliser la méthode `__int__` existante (dans la mesure où elle est implémentée par les floats, qui ne sont pas censés pouvoir indexer des slices).
 
La méthode `__index__` a donc été créé. Elle doit renvoyer un int ou un long python et permet d'utiliser n'importe quel objet comme index de slice.
 
PEP 343 - WITH statements
WITH est une fonctionalité optionnelle pour Python 2.5 disponible via from __future__ import with_statement. WITH sera activé par défaut dans Python 2.6
 
Il a pour but de simplifier et clarifier un certain nombre de constructions python utilisant auparavant try/finally en permettant d'enserrer des blocs de code avec des fonctionalités de nettoyage, par exemple un block locké (le lock est acquis au niveau du with et automatiquement relâché quand on en sort), une lecture de fichier (le fichier est ouvert avec le with et automatiquement fermé à la fin du with), ...
 
Un certain nombre d'objets Python supportent déjà WITH, principalement les objets fichiers et les locks:

with open('/etc/passwd', 'r') as f:
    for line in f:
        print line
        # 
# ici le fichier a été automatiquement refermé et l'objet associé détruit

lock = threading.Lock()
with lock:
    # section de code critique
# le lock a été relâché et peut être acquis par un autre thread

 
Il est naturellement possible de créer ses propres contextes pour le statement WITH. La chose étant quelque peu complexe, je ne peux pas partir dans une description longue ici même. Prière de lire la doc (http://docs.python.org/dev/whatsnew/pep-343.html, http://docs.python.org/dev/lib/module-contextlib.html)
 
Nouveaux modules de la stdlib (dans la logique "Best of Breed" de Python, certains existaient déjà et ont simplement été mergés dans la stdlib)
(en plus de functools et contextlib)

• cProfile, version améliorée et codée en C de l'ancien profiler Python, plus rapide, plus précis et utilisant moins de mémoire
• ctypes, Foreign Function Interface, fournit des wrappers pour types C et permet d'appeler directement des DLLs C. Permet des gains de performances appréciables
• ElementTree and cElementTree, la librairie XML Pythonique de Fredrik Lundh. Probablement le meilleure module disponible pour parser et créer du XML en Python, il est à la fois flexible, puissant, facile à utiliser
• hashlib, ajoute le support SHA-224, -256, -384, et -512 (remplace les podules SHA et MD5, SHA-1 et MD5 sont toujours disponibles via hashlib)
• msilib, pour créer des packages MSI
• pysqlite, bindings SQLite3 Python
• uuid, permet de créer des UUIDs (version 1, 3, 4 ou 5, cf RFC 4122)
• wsgiref, utilitaires et implémentation de référence de la Web Server Gateway Interface (interface standardisée pour les webservices Python)

Autres changements
 

• `dict` a maintenant une méthode `__missing__` (non utilisée par défaut) appelée quand une clé n'existe pas dans un dict.  Elle permet par exemple de mettre en place des valeurs par défaut (c'est comme ça qu'est implémenté `defaultdict` dans le module `collections`)
• `string` et `unicode` ont deux nouvelles méthodes `partition(sep)` et `rpartition(sep)`. Celles ci permettent de séparer une chaîne en 3 au niveau de la première occurence d'un séparateur. Elles renvoient un tuple de 3 données (la partie du string avant le séparateur, le séparateur et la partie du string après le séparateur)
• `startswith()` et `endswith()` peuvent maintenant prendre des tuples de strings afin de faire des recherches multiples e.g., `filename.endswith(('.gif', '.jpg', '.tiff'))`
• `min()` et `max()` prennent maintenant un nouvel argument `key`. Celui ci est une fonction qui sera appelée pour chaque objet, les objets seront classés dans l'ordre indiqué par ces valeurs de retour.
• `any()` et `all()` retournent vrai respectivement si une des valeurs et toutes les valeurs d'un iterable coercent à "True"
• Tous les modules sont maitenant codés en ASCII 8bits, tout caractère accentué y est donc interdit. Si vous voulez taper des caractères accentués dans un module, précisez sont encodage en en-tête.

Optimisations
Un bon nombre d'optimizations ayant vu le jour à la suite du spring NeedForSpeed de Rekjavik, il est intéressant de les lister ici
 

• set et frozenset sont maintenant implémentés spécifiquement (dans Python 2.4 ils étaient implémentés avec de simples dicts), ils devraient donc gagner en performances
• La vitesse de certaines opérations sur les chaînes unicodes (substrings, splitting, encodages et décodages) a été améliorée
• `long(str, base)` est maintenant notablement plus rapide sur de longues chaînes (le pic de gain étant de 6 fois plus rapide pour des chaînes de longueur 800-1000)
• Le module `struct` compile maintenant les chaînes de formats et les cache, menant à une accélération de l'ordre de 20%
• Un changement de l'allocateur utilisé dans le module `re` l'a accéléré de 1 à 2%
• Le générateur de code est maintenant capable d'effectuer des optimisations simples de type constant folding. Par exemple `a = 2 + 3` sera compilé en `a = 5`
• Les appels de fonctions ont été accélérés, et la taille des frames a été réduite (amélioration de l'état du cache et légère réduction de la consommation mémoire)
• Les exceptions Python 2.5 étant maintenant des new-style classes, leur création a été drastiquement amélioré. Il en resulte que la gestion des exceptions de Python 2.5 est 30% plus rapide que celle de Python 2.4

Voila voila, c'est tout pour cette fois, Python 2.5 est considéré stable et près à être utilisé en prod, amusez vous bien
(et je vous conseille vraiment de jeter un coup d'oeil à WITH, ce n'est pas simple mais ça vaut vraiment le coup)

Super sympa cette review
 
Ya que du bon dans cette version

à vue de nez, on dirait un équivalent du mot clé using de C# non ?

bof, C# n'a rien inventé. Mais c'est pareil, ou comme les blocks en ruby, etc

Ou comme une variation sur unwind-protect en common lisp oui.