Journal Python 2.5 beta 2

Posté par  .
Étiquettes :
0
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/
  • # Oublié

    Posté par  . É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  . É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  (site web personnel) . Évalué à 3.

        Merci à toi pour cette news de toute bôôôôté.

        Si si.
        • [^] # Re: Oublié

          Posté par  . Évalué à 2.

          Pas de proposition pour une dépêche ?
          • [^] # Re: Oublié

            Posté par  . Évalué à 2.

            Ok je le fais
            • [^] # Re: Oublié

              Posté par  . Évalué à 2.

              bah autant attendre la version finale pour la depeche
              • [^] # Re: Oublié

                Posté par  . É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
                • [^] # Re: au sujet du livre

                  Posté par  . É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.
  • # Au sujet des exceptions

    Posté par  (site web personnel) . É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  . É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  . É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  . É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 ?
      • [^] # Re: Quelques commentaires

        Posté par  (Mastodon) . É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  . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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 :)
            • [^] # Re: Quelques commentaires

              Posté par  . É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  (site web personnel) . É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)
                • [^] # Re: Quelques commentaires

                  Posté par  . É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  (site web personnel) . É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 ;-)
              • [^] # Re: Quelques commentaires

                Posté par  (site web personnel) . É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.
          • [^] # Re: Quelques commentaires

            Posté par  (site web personnel) . É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  . Évalué à 4.

            En ruby:

            File.open("/etc/fstab", "w") {|f|
            f.print "..."
            }
      • [^] # Re: Quelques commentaires

        Posté par  . É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  . É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  . É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  . É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  . É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  . É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
  • # Plus c'est gros, mieux ça passe

    Posté par  (site web personnel) . É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
  • # HAAAA

    Posté par  (Mastodon) . É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  . É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  . É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  (site web personnel) . É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.

        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

        • [^] # Re: HAAAA

          Posté par  . É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  . É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  . É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  (site web personnel) . É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.

      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

      • [^] # Petite précision

        Posté par  (site web personnel) . É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).

        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

  • # Finally

    Posté par  . É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  (site web personnel) . É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.

      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.