Dans le lot des nouveautés :
- Ajout des expressions conditionnelles ( http://docs.python.org/dev/whatsnew/pep-308.html )
>>> import os
>>> a = "ERROR" if os.system("ls") != 0 else "OK"
>>> print a
OK
- Ajout de la possibilité de faire des fonctions partielles http://docs.python.org/dev/whatsnew/pep-309.html (functools comprend des outils pour faire de la programmation fonctionnelle) :
>>> import functools
>>> def log(message, subsystem):
... print "%s: %s" % (subsystem, message)
...
>>> log("plop", "linuxfr")
linuxfr: plop
>>> linuxfr_log = functools.partial(log, subsystem="linuxfr")
>>> linuxfr_log("coin")
linuxfr: coin
- Changement des metadata pour setup.py ( http://docs.python.org/dev/whatsnew/pep-314.html) : champs Classifier, Download-URL, Requires, Provides, Obsoletes ajoutés et changement de sémantique pour les champs License et Platform qui doivent être utilisés en fonction de Classifier (si j'ai bien compris la PEP)
- Imports relatifs/absolus ( http://docs.python.org/dev/whatsnew/pep-328.html ) : ça permettra à l'avenir d'importer un module comme ça
from ..test import machin. Pour l'activer dans Python 2.5 :from __future__ import absolute_import - Exécuter des modules comme des scripts : http://docs.python.org/dev/whatsnew/pep-338.html
- Unification de "except" et "finally" : http://docs.python.org/dev/whatsnew/pep-341.html et http://www.python.org/dev/peps/pep-0341/
- yield est maintenant une expression qui retourne une valeur : http://docs.python.org/dev/whatsnew/pep-342.html
- Ajout du mot clef "with" qui est TRES pratique ( http://docs.python.org/dev/whatsnew/pep-343.html ) : au lieu de
>>> f = open("/etc/fstab", "r")où on a une variable f qui se balade un peu partout, on utilise
>>> f.readline()
'# /etc/fstab - see man 8 mount\n'>>> with open("/etc/fstab", "r") as f:. Je précise qu'il faut, pour le faire tourner sous Python 2.5 :
... print f.readline()from __future__ import with_statement - ASCII devient l'encodage par défaut (ça génère des SyntaxError à la place des Warning)
- quit() et exit() quitteront l'interpréteur
class C():est maintenant autorisé (on devait faire class C: obligatoirement)
pass- Quelques améliorations du language : http://docs.python.org/dev/whatsnew/other-lang.html#SECTION0(...)
- Optimisations ( http://docs.python.org/dev/whatsnew/other-lang.html#SECTION0(...) )
- Apparition de l'objet "Exception" ce qui permet de faciliter le except : http://docs.python.org/dev/whatsnew/pep-352.html
- Ajout de la méthode __index__ : http://docs.python.org/dev/whatsnew/pep-357.html
- Le module audioop supporte le codec a-LAW et le codec u-LAW a été amélioré
- Le module codec possède le support des codecs incrémentaux, de plus la fonction codec.lookup() retourne une instance de l'objet CodecInfo au lieu d'un tuple.
- Ajout du type "defaultdict" qui est comme un dict sauf qu'il retourne une valeur quand un objet n'est pas présent
- Ajout du module cProfile, qui est comme profile, mais en C
- Bugfixes et améliorations du module CSV
- datetime possède ENFIN un strptime, comme son voisin time, ça évite les hacks
- Le paquet email a été mis à jour en version 4.0
- Le paquet fileinput est bien plus flexible (noms de fichier unicode, et d'autres)
- Dans le module gc (garbage collector) ajout de la fonction new_count() renvoyant un tuple du rammassage pour les 3 générations (oula je traduis mal)
- Le module mailbox permet l'écriture et non plus la lecture seulement
- Ajout du module msilib permettant la créations d'installateurs au format MSI (gloups) et de fichiers CAB. Un support basique de la lecture des installateurs MSI est assuré.
- Le module nis permet aussi de naviguer sur d'autres domaines que le sien
- Mise à jour de optparse, ajout de epilog (qui ajoute un message après le --help) et un destroy()
- Ajout du benchmark pybench
- pyexpat utilise maintenant la version 2.0 du parseur Expat
- Les modules regex, regsub, statcache, tzparse et whrandom ont été supprimés. De même est supprimé le répertoire lib-old (n'affecte personne si le programme ne touche pas à sys.path pour forcer son inclusion)
- Le module rlcompleter ne nécessite pas l'inclusion de readline et donc tourne sur des plateformes non-Unix
- SimpleXMLRPCServer et DocXMLRPCServer ont un attribut rpc_path qui restreint les opérations RPC dans certains répertoires (/ et /RPC2 par défaut)
- Le module socket supporte AF_NETLINK (pour plus d'info sur netlink : http://www.linuxjournal.com/article/7356 )
- Ajout du module spwd pour accéder à /etc/shadow
- Ajout de la fonction extractall() dans le module TarFile
- Le module unicodedata a été mis à jour à la version 4.1.0 de la base de charactères unicode (pour des raisons de compatibilité l'ancien est disponible sous unicodedata.ucd_3_2_0)
- Ajout du module UUID permettant de générer des identifiants universels, conformément à la RFC 4122 ( http://www.faqs.org/rfcs/rfc4122.html )
>>> uuid.uuid1()
UUID('a8098c1a-f86e-11da-bd1a-00112444be1e') - Améliorations du module webbrowser, prise en charge de la PEP 0338, ajout de open_new(), open_new_tab(), et ajout d'un paramètre autoraise dans open()
- La librairie standard Python n'a plus de module xml, elle a été renommée en xmlcore ce qui fait qu'il est toujours possible d'appeller la librairie standard XML même si on a PyXML
- xmlrpclib permet maintenant de retourner des objets datetime
- zipfile supporte la version ZIP64 de ce format, et donc permet d'avoir un fichier zip supérieur à 4GiB et peut contenir des fichiers supérieurs à 4GiB chaqu'un.
- Ajout du paquet ctypes ( http://docs.python.org/dev/whatsnew/modules.html#SECTION0001(...) ) qui permet d'utiliser des librairies externes plus facilement qu'avec dl :
import ctypes
libc = ctypes.CDLL('libc.so.6')
result = libc.printf("Line of output\n") - ElementTree est livré de base : http://docs.python.org/dev/whatsnew/modules.html#SECTION0001(...) et ça c'est une très bonne nouvelle (c'est sur lui que se base lxml par exemple)
- Ajout de hashlib qui permet de hasher en ce qu'on veut : http://docs.python.org/dev/whatsnew/modules.html#SECTION0001(...)
- Ajout d'une implémentation WSGI : http://docs.python.org/dev/whatsnew/modules.html#SECTION0001(...)
- Quelques modifications de l'API C : http://docs.python.org/dev/whatsnew/ports.html comme la possibilité de récupérer la version complète de Python depuis C, la possibilité de compiler CPython avec un compilateur C++ (que celui qui sait en quoi c'est utile me le dise, à part nettoyer le code), et d'autres ...
- Et pour finir, quelque chose de magnifique : sqlite3 est fourni en standard avec Python !!
Voila, vous pouvez le télécharger ici : http://www.python.org/download/releases/2.5/
La PEP356 montrant le planning de Python 2.5 : http://www.python.org/dev/peps/pep-0356/
"What is new in Python 2.5" : http://docs.python.org/dev/whatsnew/whatsnew25.html
Documentation de Python 2.5 : http://docs.python.org/dev/
# Oublié
Posté par alexissoft . Évalué à 10.
* Support des Universal binaries de Mac
* Nouvelles icones pour Windows
* 60 bugs ont été fixé par l'aide de l'outil de Coverty
Notamment, comme il y avait beaucoup à traiter j'ai zappé pas mal d'autres choses, principalement présentes ici : http://docs.python.org/dev/whatsnew/modules.html
[^] # Re: Oublié
Posté par alexissoft . Évalué à 7.
[^] # Re: Oublié
Posté par charlax (site web personnel) . Évalué à 3.
Si si.
[^] # Re: Oublié
Posté par golum . Évalué à 2.
[^] # Re: Oublié
Posté par alexissoft . Évalué à 2.
[^] # Re: Oublié
Posté par roger21 . Évalué à 2.
[^] # Re: Oublié
Posté par bartman . Évalué à 2.
Miam, ça donne encore plus envie de Python
[^] # Re: au sujet du livre
Posté par cellier olivier . Évalué à 1.
D'avance merci!
Oliv.
[^] # Re: au sujet du livre
Posté par charlax (site web personnel) . Évalué à 2.
Titre : Programmation Python
Sous-titre : Syntaxe, conception et optimisation
Éditeur : Eyrolles
Collection : Blanche
Parution : janvier 2006
Édition : 1ère édition
Nb de pages : 536
ISBN : 2-212-11677-2
EAN13 : 9782212116779
http://www.editions-eyrolles.com/Livre/9782212116779/program(...)
Je confirme, il est vraiment génial et satisfaira tout le monde, du débutant à celui qui a envie d'aller plus loin.
[^] # Re: au sujet du livre
Posté par golum . Évalué à 2.
Tu dormais ou quoi
http://linuxfr.org/~tarek_ziade/
(Dois-je mettre les balises ?)
[^] # Re: au sujet du livre
Posté par golum . Évalué à 2.
http://diveintopython.org/
qui est en libre téléchargement pour patienter en attendant de recevoir celui de Tarek
# Au sujet des exceptions
Posté par Victor STINNER (site web personnel) . Évalué à 2.
BaseException inclut Exception, KeyboardInterrupt et SystemError (et peut-être d'autres). Bref, "except BaseException" attrape TOUTES les exceptions ;-)
Haypo
# Zut
Posté par Harry Da . Évalué à 1.
# Quelques commentaires
Posté par Thomas Hervé . Évalué à 2.
Quelques commentaires:
> Ajout des expressions conditionnelles
Cette syntaxe m'horripile, j'espère que cela restera dans les scripts simples et qu'on ne verra pas ca dans des bibliothèques. La lisibilité est très douteuse je trouve.
> yield est maintenant une expression qui retourne une valeur
C'est une nouvelle plus importante qu'elle ne paraît :). Cela permet de communiquer entre un générateur et la fonction appelante, et donc de créer un pseudo système de coroutine (ce n'est pas exactement cela non plus je trouve).
> Ajout du mot clef "with" qui est TRES pratique
Mouais, pareil que plus haut, je trouve ca intéressant pour un petit script, mais le côté magique qui se cache derrière me rebute un peu.
> ElementTree est livré de base :
>http://docs.python.org/dev/whatsnew/modules.html#SECTION0001(...)
> et ça c'est une très bonne nouvelle (c'est sur lui que se base lxml
> par exemple)
Oui c'est très bon ElementTree, mangez-en! Il définit une nouvelle API propre à Python qui est très intuitive et performante. Refaire du DOM après est un calvaire. Note par contre que lxml n'est pas basé sur etree, il adopte juste cette API.
> Et pour finir, quelque chose de magnifique : sqlite3 est fourni en
> standard avec Python !!
Oui, c'est très intéressant, c'est un choix que php5 avait déjà fait. Par contre il faut toujours avoir sqlite3 d'installé auparavant.
--
Thomas
[^] # Re: Quelques commentaires
Posté par goeb . Évalué à 1.
et le "with", ça fait quoi exactement ? c'est utile ?
[^] # Re: Quelques commentaires
Posté par Yth (Mastodon) . Évalué à 3.
x=(a>b)?a:b
C'est plutôt pratique en fait...
Yth.
[^] # Re: Quelques commentaires
Posté par alexissoft . Évalué à 3.
[^] # Re: Quelques commentaires
Posté par golum . Évalué à 5.
z = if (a>b) then a else b
c'est homogène avec le c
z= (a>b)?a:b
la condition au début et les branchements ensuite.
[^] # Re: Quelques commentaires
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 2.
C'est tout non ?
[^] # Re: Quelques commentaires
Posté par durandal . Évalué à 2.
[^] # Re: Quelques commentaires
Posté par TImaniac (site web personnel) . Évalué à 3.
En C# on peut faire :
using( FileWriter fw = new FileWriter("toto.log") )
{
fw.Write("coucou");
}
à la fin de la clause using, la méthode "Dispose" (interface IDisposable) du FileWriter est appelée, en l'occurence ca ferme le fichier, ce qui correspond au __exit__. Le __enter__, ben l'équivalent serait le constructeur :)
[^] # Re: Quelques commentaires
Posté par golum . Évalué à 3.
J'aime pas ces syntaxes implicites qui font des trucs dans notre dos.
Tu passes toujours 2 h avant de comprendre ce qui s'est vraiment passé quand tu as oublié l'astuce ou que tu découvres le langage
[^] # Re: Quelques commentaires
Posté par TImaniac (site web personnel) . Évalué à 4.
De plus une écriture "naïve" aurait pu conduire à faire :
FileWriter fileWriter = new FileWriter("toto.log");
//somework
fileWriter.Close();
Et si une erreur survient pendant l'utilisation du fichier ? (genre erreur d'entrée/sortie)
L'avantage de cette syntaxe, c'est qu'elle t'assure que ton fichier soit fermé, même si une exception est levée au milieu du using.
Tu trouves ca plus élégant d'écrire :
FileWriter fileWriter = new FileWriter("toto.log");
try{
// some work
}
finally
{
fileWriter.Close();
}
Non franchement c'est pas plus joli, le using est bien plus simple à comprendre.
Je suppose que tu as le même avis sur la boucle foreach et yield ?
Je suppose que tu n'aimes pas non plus le garbage collector qui nettoie la mémoire par magie ? D'ailleur tu n'aimes pas non plus le C++ car il appelle automatiquement le destructeur d'une variable déclarée localement ? (ce qui correspond grosso-modo au using ici)
[^] # Re: Quelques commentaires
Posté par golum . Évalué à 4.
Merci pour la leçon ;-)
[^] # Re: Quelques commentaires
Posté par TImaniac (site web personnel) . Évalué à 3.
Le plus génant au final, c'est que le pattern "Dispose" pour lébérer un objet de manière deterministe devient confu pour le néophite qui doit se mélanger les pinceaux après avoir vu au chapitre précédent qu'il y a une syntaxe pour le destructeur en C# (mais qui lui est non déterministe)...
En tout cas perso je me mélange parfois les pédales quand je passe de C# à CLI/C++ (et inversement) :)
FIn de la pub ;-)
[^] # Re: Quelques commentaires
Posté par Fabimaru (site web personnel) . Évalué à 1.
- ouvrir fichier / fermer fichier
- prendre mutex / relacher mutex
- demarrer trace / arreter trace
J'en use et abuse en C++, ça permet d'éviter des tas de bugs.
[^] # Re: Quelques commentaires
Posté par hocwp (site web personnel) . Évalué à 3.
[^] # Re: Quelques commentaires
Posté par Hank Lords . Évalué à 4.
File.open("/etc/fstab", "w") {|f|
f.print "..."
}
[^] # Re: Quelques commentaires
Posté par Thomas Hervé . Évalué à 1.
lock = threading.Lock() with lock: # Critical section of codeDe plus, c'est personnalisable, on peut imaginer pas mal de choses, comme des transactions au niveau du code. Mais ce n'est que du 'sucre syntaxique', donc rien que l'on ne pouvait faire avant (avec plus de code il est vrai).[^] # Re: Quelques commentaires
Posté par Emmanuel C . Évalué à 4.
def updateSthg(data): lock = myLockingFunction() myData = int(data) lock.unlock()Maintenant, si l'utilisateur entre une chaine de caractère "toto" dans data, une exception sera générée, et le verrou jamais libéré. Dommage, non. Il faudrait faire des try et des except, relacher le verrou pour ensuite relancer l'exception, etc. Pas tres pratique, non ? Avec with :def updateSthg(data): lock = myLockingMechanism() with lock: myData = int(data)Là, la personne qui a programmé le "myLockingMechanism" est *garantie* et c'est là que c'est important, que quelque soit le flux d'exécution, elle aura la main pour libérer le verrou. Peu importe de savoir ce qui se passe en interne. Le but est que l'écriture de code haut niveau soit simple ET robuste, en s'appuyant sur des bibliothèques qui seront elles plus complexes, mais suffisament outillées pour rester compréhensible sans utiliser de bidouilles non standardisées. Alors oui, il y a de la magie, mais dans toute couche d'abstraction, il y a de la magie. Si on utilise python, c'est parce que c'est simple. Il ne faut pas se leurrer, l'interpréteur cpython n'est sans doute pas du même niveau.[^] # Re: Quelques commentaires
Posté par Thomas Hervé . Évalué à 1.
lock = threading.Lock() with lock: # Critical section of codeest tout à fait équivalent àlock = threading.Lock() try: # Critical section of code finally: lock.release()Le dernier est explicite, alors que with contient un fonctionnement implicite. Tout est une question d'habitude après, mais ce n'est pas une révolution en tout cas.[^] # Re: Quelques commentaires
Posté par Emmanuel C . Évalué à 1.
L'interet des with, c'est surtout pour les gens qui vont faire des bibliothèques, qui sont en général considérées comme étant des boites noires. Alors les appels implicites, dans ce cas, n'ont finalement que peu d'importance, puisqu'une bibliothèque, c'est en général toujours implicite.
[^] # Re: Quelques commentaires
Posté par Sylvain Sauvage . Évalué à 2.
Ah merde. Tu veux dire que ça pourrait être une bonne idée de forcer le try dans certains cas ?
Cherchez pas -->[]
# Moins de memory leak
Posté par jon . Évalué à 3.
Pour plus d'infos :
- http://evanjones.ca/python-memory.html
- http://evanjones.ca/python-memory-part2.html
- http://evanjones.ca/python-memory-part3.html
[^] # Re: Moins de memory leak
Posté par wilk . Évalué à 1.
# Plus c'est gros, mieux ça passe
Posté par Victor STINNER (site web personnel) . Évalué à -2.
Je vous laisse relire 4x ces phrases.
Haypo
[^] # Re: Plus c'est gros, mieux ça passe
Posté par alexissoft . Évalué à 6.
# HAAAA
Posté par Yusei (Mastodon) . Évalué à 7.
Mais quelle HORREUR !
Qu'y avait-il de mal avec une syntaxe plus classique du style
a = if (os.system("ls") != 0) then "ERROR" else "OK" end ?
C'est tout dans le désordre cette forme là.
[^] # Re: HAAAA
Posté par alexissoft . Évalué à 2.
[^] # Re: HAAAA
Posté par durandal . Évalué à 3.
J'accroche pas non plus à cette syntaxe, mais y'a des arguments intéressants. Si on considère que c'est pour gérer des cas spéciaux ça permet en effet de voir bien clairement ce qui se passe dans le cas général et l'exception et le cas particulier.
Mais bon l'ajout de ce type de syntaxes ne simplifie pas le langage.
[^] # Re: HAAAA
Posté par lolop (site web personnel) . Évalué à 3.
Mais vu les artefacts utilisés par certains, autant que qq chose d'un peu plus clair existe... et heureusement, on n'est pas obligé de l'utiliser.
A réserver à des cas particuliers et faciles à lire/comprendre.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: HAAAA
Posté par Emmanuel C . Évalué à 1.
L'important, c'est que ce soit une expression, et non pas un statement (qui peut lui même contenir plusieurs blocs). Après, les querelles de syntaxes rejoignent les querelles d'indentation en C...
# ASCII devient l'encodage par défaut
Posté par mickabouille . Évalué à 0.
De toute façon, prendre l'ASCII par défaut me semble le pire choix de tous.
[^] # Re: ASCII devient l'encodage par défaut
Posté par alexissoft . Évalué à 3.
Par contre la première ligne # -*- coding: utf-8 -*- existe encore.
Je cite http://docs.python.org/dev/whatisnew/ :
[^] # Re: ASCII devient l'encodage par défaut
Posté par lolop (site web personnel) . Évalué à 4.
Dès qu'on s'en écarte, ça oblige tous les développeurs à indiquer au début des sources (# -*- encoding: xxx -*-) quel encodage ils ont utilisé. Ainsi lorsqu'un module passe d'une machine à une autre, Python (mais aussi les éditeurs qui y sont adapté) sait dans quel encodage est le fichier et le traite correctement.
Avant l'encodage par défaut était l'ascii... sauf si on le modifiait (sys.setdefaultencoding() [*]) - maintenant ça n'est plus modifiable, on ne risque plus d'envoyer à quelqu'un un module qui présuppose un encodage par défaut identique à celui que l'on a localement.
Une des maximes Python: "Explicit is better than implicit."
A+
Laurent.
[*] qui n'était dispo que lors de l'exécution les sitecustomize ou qq chose comme ça.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Petite précision
Posté par lolop (site web personnel) . Évalué à 4.
Elle n'a aucun impact sur les autres chaînes str - celles-ci n'ont pas d'attribut d'encodage et peuvent contenir n'importe quelles données binaires (même des octets zéro). Si une de ces chaines str passe de ton module à un autre module qui utilise un autre encodage, le fait d'être resté en str fait que ta chaîne sera mal interprétée.
Conclusion: s'il y autre-chose que de l'ascii dans un texte... passez le en Unicode (et faites les conversions ad-hoc en entrée et en sortie, en connaissant ce qui est attendu comme encodage).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Finally
Posté par golum . Évalué à 2.
était vraiment le truc que j'attendais le plus
http://www.python.org/dev/peps/pep-0341/
Manque plus que le do while
http://www.python.org/dev/peps/pep-0315/
Marrant à un moment il l'avait ecarté et la revoilà au goût du jour.
Là elle est deferred
Vivement la 2.6.
[^] # Re: Finally
Posté par lolop (site web personnel) . Évalué à 2.
do:
. [setup code]
while [condition]:
. [loop body]
Car personnellement j'ai du mal à y voir que le setup code est réexécuté à chaque itération.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.