lundi 17 novembre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de linuxcode :

[17/06@11:22] FON et les serveurs de temps
[23/01@12:14] La tribune va devenir payante !!
[19/12@16:31] N'utilisez pas arts !
[16/11@14:07] Nouveau design pour sourceforge
[18/10@20:52] Google Kai
[23/09@18:48] LibreStory, la téléréalité de linuxfr
[06/06@20:59] Et oui c'est officiel maintenant, sarge est sorti
[02/03@22:22] BILL GATES PASSE A KAMELOT
[26/01@13:35] Enregistrement numérique avec linux
[08/01@16:13] Recherche développeurs pour projet de distribution libre
[11/12@17:19] ROT13v2 en Python
[06/12@21:14] Micro-SDRAM pour l'intégration dans microprocesseurs
[21/06@22:20] 2.6.7 out
[15/06@15:35] Développeur cherche le PieD de linuxfr désespérément
[09/05@21:13] Comment arriver à devenir fou avec des penny ? (ou l'histoire d'IPv6 ;) )

Journal : Python 2.5 beta 2

Posté par alexissoft (Jabber id, page perso, ) le 22 juin 2006

Python 2.5 beta 2 est sorti il y a peu, le 20 juin. D'après le planning, la beta 2 sortira le 12 juillet, la rc1 le 1 août, et pour finir il sera dévoilé au monde entier dans sa version finale le 8 août 2006.

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") >>> f.readline() '# /etc/fstab - see man 8 mount\n' où on a une variable f qui se balade un peu partout, on utilise >>> with open("/etc/fstab", "r") as f: ... print f.readline(). Je précise qu'il faut, pour le faire tourner sous Python 2.5 : 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(): pass est maintenant autorisé (on devait faire class C: obligatoirement)

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/

> Lire le journal (48 commentaires, moyenne: 2,7).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Oublié

Posté par alexissoft (Jabber id, page perso, ) le 22/06/2006 à 14:44. (lien). Évalué à 10.

Tiens en relisant j'ai remarqué que j'avais oublié ça :
* 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 (Jabber id, page perso, ) le 22/06/2006 à 14:50. (lien). Évalué à 7.
aïe, et aussi, vous corrigerez bien sûr, il s'agit de Python beta 1 et pas Python beta 2 (j'aurai vraiment du mieux relire)
- [^]Re: Oublié
  
  Posté par charlax (page perso, ) le 22/06/2006 à 15:24. (lien). Évalué à 3.
  Merci à toi pour cette news de toute bôôôôté.
  
  Si si.
  - [^]Re: Oublié
    
    Posté par golum () le 22/06/2006 à 15:37. (lien). Évalué à 2.
    Pas de proposition pour une dépêche ?
    - [^]Re: Oublié
      
      Posté par alexissoft (Jabber id, page perso, ) le 22/06/2006 à 15:49. (lien). Évalué à 2.
      Ok je le fais
      - [^]Re: Oublié
        
        Posté par roger21 () le 22/06/2006 à 16:24. (lien). Évalué à 2.
        bah autant attendre la version finale pour la depeche
        
        [^]Re: Oublié
        
        Posté par bartman () le 23/06/2006 à 08:19. (lien). Évalué à 2.
        j'ajoute ma voix aussi, étant en train de découvrir Python en ce moment (le livre de T Zadieh est terrible) je trouve que malgré tes petits oublis, c'est une nouvelle vraiment intéressante et surtout bien détaillée.
        
        Miam, ça donne encore plus envie de Python
        
        --
        Parler pour ne rien dire et ne rien dire pour parler sont les deux principes majeurs et rigoureux de tous ceux qui feraient mieux de la fermer avant de l'ouvrir.
        
        [^]Re: au sujet du livre
        
        Posté par cellier olivier () le 28/06/2006 à 16:25. (lien). Évalué à 1.
        peux-tu donner, stp, les références exactes du livre dont tu parles? Car, si google est mon ami, il ne trouve pas grand chose ;-)))
        
        D'avance merci!
        
        Oliv.
        
        [^]Re: au sujet du livre
        
        Posté par charlax (page perso, ) le 28/06/2006 à 19:38. (lien). Évalué à 2.
        Il s'agit de ce livre :
        
        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 () le 28/06/2006 à 20:53. (lien). Évalué à 2.
        C'est pas possible, tu n'as pas pu le rater sur DLFP avec toute la pub qui a été faite par l'auteur.
        Tu dormais ou quoi
        http://linuxfr.org/~tarek_ziade/
        
        (Dois-je mettre les balises ?)
        
        [^]Re: au sujet du livre
        
        Posté par golum () le 28/06/2006 à 20:56. (lien). Évalué à 2.
        Ah et si tu n'es pas anglophobe tu peux aussi te plonger au coeur de python
        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 (page perso, ) le 22/06/2006 à 15:53. (lien). Évalué à 2.

Ça va plus vite (30% plus vite), mais c'est la classe BaseException qui fait son apparition, pas Exception :-p

BaseException inclut Exception, KeyboardInterrupt et SystemError (et peut-être d'autres). Bref, "except BaseException" attrape TOUTES les exceptions ;-)

Haypo

Zut

Posté par Kévin LAPETOULE (page perso, ) le 22/06/2006 à 16:05. (lien). Évalué à 1.

Bheu, c'est pas possible que ce soit un journal, ca ressemble plus à une dépêche. Merde j'ai du me planter dans mes bookmarks, je...ha ben nan...comprend plus rien. C'est bien une dépêche non ?

Quelques commentaires

Posté par Thomas Hervé () le 22/06/2006 à 16:37. (lien). Évalué à 2.

D'abord bravo pour ton journal, j'espère que tu proposera une dépêche d'aussi bonne qualité pour la sortie finale :).

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 (page perso, ) le 23/06/2006 à 08:12. (lien). Évalué à 1.
je suis d'accord, les expressions conditionnelles ça rend moins lisible et ça n'apporte rien.

et le "with", ça fait quoi exactement ? c'est utile ?

--
goeb
- [^]Re: Quelques commentaires
  
  Posté par Yth (Jabber id, ) le 23/06/2006 à 09:22. (lien). Évalué à 3.
  Ben c'est l'équivalent du C :
  x=(a>b)?a:b
  
  C'est plutôt pratique en fait...
  
  Yth.
  - [^]Re: Quelques commentaires
    
    Posté par alexissoft (Jabber id, page perso, ) le 23/06/2006 à 09:50. (lien). Évalué à 3.
    Ca c'est les expressions conditionnelles :
    
    >>> import os
    >>> a = "ERROR" if os.system("ls") != 0 else "OK"
    >>> print a
    OK
    - [^]Re: Quelques commentaires
      
      Posté par golum () le 23/06/2006 à 13:27. (lien). Évalué à 5.
      Sauf que comme le remarque Yusei un peu plus bas un if qui se ballade au milieu comme dans perl, ca fait tache.
      
      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 (Jabber id, page perso, ) le 23/06/2006 à 09:46. (lien). Évalué à 2.
  Le «with», d'après ce que j'ai compris dans l'excellent journal (j'en remets une couche ;-) ), sert à limiter la porter de la variable au bloc «with».
  
  C'est tout non ?
  - [^]Re: Quelques commentaires
    
    Posté par durandal () le 23/06/2006 à 11:43. (lien). Évalué à 2.
    Et ça marche en implémentant des méthodes __enter__ et __exit__ pour l'objet en question. Je me demande si y'a un équivalent dans un autre langage.
    - [^]Re: Quelques commentaires
      
      Posté par TImaniac (page perso, ) le 23/06/2006 à 12:25. (lien). Évalué à 3.
      <i>Je me demande si y'a un équivalent dans un autre langage.</i>
      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 :)
      
      --
      MonoFrance
      - [^]Re: Quelques commentaires
        
        Posté par golum () le 23/06/2006 à 13:31. (lien). Évalué à 3.
        et pourquoi ne pas utiliser $_ tant que tu y es.
        
        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 (page perso, ) le 23/06/2006 à 23:28. (lien). Évalué à 4.
        Euh, globalement je préfères oublier l'astuce (et donc ne pas l'utiliser), que d'oublier de fermer mon fichier hein :)
        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)
        
        --
        MonoFrance
        
        [^]Re: Quelques commentaires
        
        Posté par golum () le 24/06/2006 à 08:39. (lien). Évalué à 4.
        Je savais qu'en te titillant un peu tu allais argumenter un peu et faire autre chose que de la pub pour ton langage préféré.
        
        Merci pour la leçon ;-)
        
        [^]Re: Quelques commentaires
        
        Posté par TImaniac (page perso, ) le 25/06/2006 à 21:28. (lien). Évalué à 3.
        Cela dis le using en C# peut aussi être critiqué hein :) Comme je l'ai expliqué, le using est fortement lié à l'implémentation de l'interface IDisposable par la classe définissant l'objet utilisé. En soit c'est le résultat souhaité et l'écriture est relativement élégante. Mais d'un point de vue design du langage, le using est un mot clé (et pour cause il a une syntaxe particulière), alors que l'interface IDisposable est une bête classe de la bibliothèque (standard certe). Je trouves pas ca très "clean", le support de l'interface IDisposable aurait-elle dû être mise dans le langage comme ils l'ont fait avec le langage C++/CLI (où c'est le destructeur qui joue le rôle d'implémentation de l'interface IDisposable) ?
        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 ;-)
        
        --
        MonoFrance
        
        [^]Re: Quelques commentaires
        
        Posté par Tennis Prono (page perso, ) le 24/06/2006 à 09:17. (lien). Évalué à 1.
        Et moi ça me gave un peu de faire:
        - 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.
        
        --
        Pas de bureau 3d libre sans drivers libres!
    - [^]Re: Quelques commentaires
      Posté par hocwp (page perso, ) le 23/06/2006 à 12:44. (lien). Évalué à 3.
      Ca ressemble très fortement au with du Common Lisp :
      (with-open-file (f "/etc/fstab" :direction :ouput) (write-line "..." f))
      Le fichier est ouvert et automatiquement fermé à la sortie de la macro avec la garantie qu'il soit fermé même si une erreur survient (open/close entouré d'un unwind-protect). http://www.lisp.org/HyperSpec/Body/mac_with-open-file.html
    - [^]Re: Quelques commentaires
      
      Posté par Hank Lords (Jabber id, ) le 23/06/2006 à 12:51. (lien). Évalué à 4.
      En ruby:
      
      File.open("/etc/fstab", "w") {|f|
      f.print "..."
      }
- [^]Re: Quelques commentaires
  Posté par Thomas Hervé () le 23/06/2006 à 14:27. (lien). Évalué à 1.
  Il y a aussi une utilisation intéressante avec les threads, présentée ici: http://docs.python.org/dev/whatsnew/pep-343.html :
```
lock = threading.Lock()
with lock:
    # Critical section of code
```
  De 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 () le 23/06/2006 à 20:35. (lien). Évalué à 4.
    Hmmm, tout depend de ce que tu appelle du sucre syntaxique. L'utilisatation du "with" avec les Lock(), c'est exactement ce que fait Java avec ces synchronize. Le but en java était de s'assurer qu'un verrou était toujours relaché, ce qui permettait d'éviter les deadlocks pour cause de relachement non effectué. Exemple (sans with) :
```
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é () le 24/06/2006 à 17:46. (lien). Évalué à 1.
      Non pour moi c'est du sucre syntaxique quand même :). Quand tu utilises un lock, tu sais que tout code l'utilisant doit être dans un try/finally. Donc :
      lock = threading.Lock() with lock: # Critical section of code
      est 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 () le 26/06/2006 à 15:08. (lien). Évalué à 1.
        L'inconvenient du try/finally, c'est qu'il faut y penser. Cela dit, ton exemple reste valable.
        
        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 () le 27/06/2006 à 19:40. (lien). Évalué à 2.
        
        L'inconvenient du try/finally, c'est qu'il faut y penser. Cela dit, ton exemple reste valable.
        
        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 Jonathan Ballet (Jabber id, ) le 22/06/2006 à 16:43. (lien). Évalué à 3.

Également, un patch qui permet de limiter les effets de memory leak, présent sur les processus qui tournent pendant longtemps (genre les serveurs écrits en Python, Zope, etc.)

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 (Jabber id, page perso, ) le 23/06/2006 à 12:59. (lien). Évalué à 1.
Tu sais si y a des chances que ce soit backporté ?

[+] Plus c'est gros, mieux ça passe

Posté par Victor STINNER (page perso, ) le 22/06/2006 à 20:16. (lien). Évalué à -2.

« Python 2.5 beta 2 est sorti il y a peu, le 20 juin. D'après le planning, la beta 2 sortira le 12 juillet »

Je vous laisse relire 4x ces phrases.

Haypo

[^]Re: Plus c'est gros, mieux ça passe

Posté par alexissoft (Jabber id, page perso, ) le 22/06/2006 à 21:03. (lien). Évalué à 6.
Cf http://linuxfr.org/comments/726056.html#726056

HAAAA

Posté par Yusei () le 22/06/2006 à 21:21. (lien). Évalué à 7.

a = "ERROR" if os.system("ls") != 0 else "OK"

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 (Jabber id, page perso, ) le 22/06/2006 à 21:38. (lien). Évalué à 2.
A mon avis c'est pour aller mieux dans l'optique des [i/2.0 for i in range(0,5)] (bon là l'exemple est VRAIMENT pourri)

[^]Re: HAAAA

Posté par durandal () le 23/06/2006 à 06:37. (lien). Évalué à 3.
La discussion sur ce point est ici : http://docs.python.org/dev/whatsnew/pep-308.html

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 Laurent Pointal (page perso, ) le 23/06/2006 à 13:30. (lien). Évalué à 3.
  Je n'aime pas trop non plus.
  
  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.
  
  --
  (pub: Livres à prix réduit sur http://www.sollire.com/ - la boutique de mes petites soeurs)
  - [^]Re: HAAAA
    
    Posté par Emmanuel C () le 23/06/2006 à 20:38. (lien). Évalué à 1.
    ça sert tout simplement à faire des conditions dans des lambda...
    
    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 Mickaël L () le 23/06/2006 à 09:33. (lien). Évalué à 0.

C'était quoi l'encodage par defaut avant? Si je me souviens bien je n'ai jamais utilisé l'ASCII ça c'est sûr.

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 (Jabber id, page perso, ) le 23/06/2006 à 09:54. (lien). Évalué à 3.
Avant c'était de l'iso-8859 par défaut, et donc ça mettait un bordel monstre.

Par contre la première ligne # -*- coding: utf-8 -*- existe encore.

Je cite http://docs.python.org/dev/whatisnew/ :

ASCII is now the default encoding for modules. It's now a syntax error if a module contains string literals with 8-bit characters but doesn't have an encoding declaration. In Python 2.4 this triggered a warning, not a syntax error. See PEP 263 ( http://www.python.org/peps/pep-0263.html ) for how to declare a module's encoding; for example, you might add a line like this near the top of the source file:
# -*- coding: latin1 -*-

[^]Re: ASCII devient l'encodage par défaut

Posté par Laurent Pointal (page perso, ) le 23/06/2006 à 13:15. (lien). Évalué à 4.
Non, prendre l'ascii par défaut est le meilleur choix. C'est le plus petit dénominateur commun.

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.

--
(pub: Livres à prix réduit sur http://www.sollire.com/ - la boutique de mes petites soeurs)
- [^]Petite précision
  
  Posté par Laurent Pointal (page perso, ) le 23/06/2006 à 13:23. (lien). Évalué à 4.
  La directive d'encodage au début du fichier source permet à Python de transformer correctement les chaînes litérales déclarées comme étant Unicode u"Une chaîne unicode".
  
  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).
  
  --
  (pub: Livres à prix réduit sur http://www.sollire.com/ - la boutique de mes petites soeurs)

Finally

Posté par golum () le 23/06/2006 à 14:16. (lien). Évalué à 2.

le try except finally à la java
é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 Laurent Pointal (page perso, ) le 23/06/2006 à 14:33. (lien). Évalué à 2.
Hum, AMA pour le do / while, faudrais trouver une autre syntaxe que:
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.

--
(pub: Livres à prix réduit sur http://www.sollire.com/ - la boutique de mes petites soeurs)

Revenir en haut de page

Journal : Python 2.5 beta 2

Oublié

[^]Re: Oublié

[^]Re: Oublié

[^]Re: Oublié

[^]Re: Oublié

[^]Re: Oublié

[^]Re: Oublié

[^]Re: au sujet du livre

[^]Re: au sujet du livre

[^]Re: au sujet du livre

[^]Re: au sujet du livre

Au sujet des exceptions

Zut

Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

[^]Re: Quelques commentaires

Moins de memory leak

[^]Re: Moins de memory leak

[+] Plus c'est gros, mieux ça passe

[^]Re: Plus c'est gros, mieux ça passe

HAAAA

[^]Re: HAAAA

[^]Re: HAAAA

[^]Re: HAAAA

[^]Re: HAAAA

ASCII devient l'encodage par défaut

[^]Re: ASCII devient l'encodage par défaut

[^]Re: ASCII devient l'encodage par défaut

[^]Petite précision

Finally

[^]Re: Finally