Nouvelle version majeure de Python (2.6)

Posté par  (site web personnel) . Modéré par rootix.
Étiquettes : aucune
31
2
oct.
2008
Python
En attendant la sortie de Python3 prévue mi-octobre, le langage de programmation Python sort en version 2.6. Cette version vise à préparer la migration vers Python3 et apporte énormément de nouveautés, aussi bien dans le langage que dans la bibliothèque standard. Les principales nouveautés sont décrites dans la seconde partie de cet article.

Le développement de Python est ouvert et suit les propositions d'améliorations (PEP). L'outil de suivi de bugs (bugs.python.org) a migré de Sourceforge à une installation personnalisée de Roundup. La documentation LaTeX a été convertie dans le format reStructuredText et est maintenant compilée avec l'outil Sphinx, développé pour l'occasion. Améliorations du langage
  • La PEP 3101 (Advanced String Formatting) révolutionne la manière de formater une chaîne de caractères. Exemples : "{0} {1}!".format("Hello", "World") ou "objet={obj}, taille={obj.taille}".format(obj=mon_objet). On peut réutiliser un argument plusieurs fois, changer l'ordre des arguments, lire un attribut d'un objet, lire un valeur dans un dictionnaire, etc.
  • La PEP 3119 (Introducing Abstract Base Classes) permet de spécifier qu'une classe implémente une interface. Exemples d'ABC : Hashable, Iterator, Sized. Voir aussi la PEP 3141 (A Type Hierarchy for Numbers).
  • Grâce à la PEP 3129 (Class Decorators), les décorateurs sont maintenant applicables aux classes.
  • L'usage de with se généralise et est simplifié par la création du module contextmanager.

Nouveaux modules et nouvelles classes
  • Le module multiprocessing est une réponse à la parallélisation massive des ordinateurs (processeurs multi-cœurs). Il permet d'exécuter une fonction dans plusieurs processus séparés de manière transparente. Rappel : à cause du Global Interpreter Lock (GIL), Python est incapable d'exécuter plusieurs threads en parallèle.
  • Le module json gère la sérialisation d'objets dans le format JavaScript Object Notation (supporte l'import et l'export).
  • Le module fractions contient la classe Fraction qui stocke la valeur exacte d'une fraction que les nombres flottants ne peuvent qu'approximer. D'ailleurs, le type float() supporte maintenant les valeurs « nan » (not an number), « +inf » et « -inf ».

Compatibilité avec Python3

Nombreuses fonctionnalités Python3 sont accessibles de manière optionnelles, par exemple par le module future_builtins :
  • Avec « from __future__ import print_function », on peut utiliser print comme une simple fonction, alors que par défaut c'est un mot clé dans Python2. Exemple : print("Hello", "World", sep="_", end="!\n", file=sys.stdout) affiche « Hello_World! ». Lire la PEP 3105 (Make print a function).
  • Les nombres peuvent être écrits directement en binaire. Le nouveau préfixe octal est « 0o ». Exemples : deux = 0b10 et dix=0o10. Lire la PEP 3127 (Integer Literal Support and Syntax).
  • La PEP 3110 (Catching Exceptions in Python 3000) introduit une notation alternative pour les exceptions : « except (ValueError, TypeError) as err: ». Elle évite les erreurs du type « except ValueError, TypeError: ».
  • Création du type bytes() qui est en fait un alias de str(). La PEP 3112 (Bytes literals in Python 3000) introduit les chaînes d'octets littérales : b'octets' est équivalent à 'octets'. Sauf avec « from __future__ import unicode_literals », dans quel cas les chaînes seront considérées de type unicode : 'unicode' vs b'octets').
  • La PEP 3116 (New I/O) décrit le module io, la nouvelle bibliothèque d'entrée/sortie. Par défaut, c'est l'ancienne bibliothèque qui est utilisée. Utilisez par exemple io.open() pour accéder à vos fichiers textes en unicode.

Interprète Python
  • Un utilisateur peut installer des modules Python dans son dossier personnel. Exemple : dossier « ~/.local/lib/python2.6/site-packages » dans le cas de Linux.
  • Il est désormais possible de contrôler l'écriture des scripts Python compilés (.pyc et .pyo) avec l'option -B de Python et la variable d'environnement PYTHONDONTWRITEBYTECODE.

Faut-il migrer à Python3 ?

Python2 n'est pas près d'être remplacé par Python3. La migration se fera en douceur et progressivement.

Pour l'instant, il est recommandé d'écrire du code Python2 et le convertir avec l'outil 2to3 (intégré dans Python 2.6). En cas de problème, corriger le code original en évitant, dans la mesure du possible, d'introduire des tests sur le numéro de version.

Sachant que des projets ont mis plusieurs mois à migrer de Python 2.4 à Python 2.5, il y a peu de chance pour que les projets majeurs migrent complètement à Python3.

Python 2.7 est déjà prévu et améliorera encore la compatibilité entre Python2 et Python3. En attendant, Python 3.0 nous réserve encore quelques surprises (comme les arguments sous forme de mot clé uniquement, oups, ce n'est plus une surprise) !

Aller plus loin

  • # dix???

    Posté par  (site web personnel) . Évalué à 9.

    Le nouveau préfixe octal est « 0o ». Exemples : deux = 0b10 et dix=0o10

    heu... c'est pas plutôt huit=0o10 , ou j'ai rien compris?

    • [^] # Re: dix???

      Posté par  (site web personnel) . Évalué à 3.

      c'est huit(base 10) = 0o10 (base octale)

    • [^] # Re: dix???

      Posté par  (site web personnel) . Évalué à 4.

      ça ne reste jamais que le nom d'une variable...

      • [^] # Re: dix???

        Posté par  . Évalué à 5.

        Sauf qu'une variable intelligemment nommée décrit ce qu'elle contient.

    • [^] # Re: dix???

      Posté par  (site web personnel) . Évalué à 2.

      Peu importe puisque c'est correct en base 42 (si, si !).

    • [^] # Re: dix???

      Posté par  . Évalué à 1.

      Effectivement si le nom de la variable indique ce quelle contient, on devrait lire:
      dix=0o12

      • [^] # Re: dix???

        Posté par  . Évalué à 2.

        et la renommer quand on l'incrémente ? pfiou ça va devenir chaud de faire du code lisible ;)

  • # GIL

    Posté par  . Évalué à 2.

    Vu sur http://docs.python.org/dev/library/multiprocessing.html :

    multiprocessing is a package that supports spawning processes using an API similar to the threading module. The multiprocessing package offers both local and remote concurrency, effectively side-stepping the Global Interpreter Lock by using subprocesses instead of threads. Due to this, the multiprocessing module allows the programmer to fully leverage multiple processors on a given machine. It runs on both Unix and Windows.

    • [^] # Re: GIL

      Posté par  . Évalué à 4.

      Euh, oui, et? C'est exactement ce que disait Victor, non? Le nouveau module permet d'utiliser efficacement les multi-coeurs en s'appuyant sur des processus distincts, puisqu'avec des threads ça ne peut pas marcher à cause du GIL.

      Ou bien j'ai raté un truc?

      • [^] # Re: GIL

        Posté par  (site web personnel) . Évalué à 3.

        Ou bien j'ai raté un truc ?

        croire que tout le monde RTFA* ? :D

        * en:RTFA tout en bas

      • [^] # Re: GIL

        Posté par  . Évalué à 1.

        A ce sujet, j'ai découvert Stackless Python il y a peu (http://www.stackless.com/ )
        Est-ce que qqun sait s'il y a une coopération avec le Python legacy ?

        • [^] # Re: GIL

          Posté par  . Évalué à 1.

          Stackless Python est une modification assez extensive de l'interpréteur standard. Il n'y a pas de coopération entre les deux équipes (celle de Stackless étant à mon avis très réduite), mais le fait que Stackless soit dérivé de CPython implique qu'il n'y aura pas divergence, sauf sur les points qui précisément sont la raison d'être de Stackless.

        • [^] # Re: GIL

          Posté par  (site web personnel) . Évalué à 4.

          Pour les alternatives aux threads, je te conseille de regarder du projet PyPy. Il a déjà intégré une partie de (ou tout ?) Stackless Python.

    • [^] # Re: GIL

      Posté par  (site web personnel) . Évalué à 2.

      Pour utiliser les threads en Python... suffit d'utiliser IronPython \o/
      http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPytho(...)

      • [^] # Re: GIL

        Posté par  . Évalué à 2.

        et .NET, donc poubelle.

        • [^] # Re: GIL

          Posté par  (site web personnel) . Évalué à 3.

          pas besoin de .NET, juste d'une implémentation correcte de la CLI et du CLR, 2 standards définis par l'ECMA et l'ISO.

          • [^] # Re: GIL

            Posté par  . Évalué à 7.

            oh oui alors hein, alors les standards de l'ECMA et de l'ISO, hein, depuis le gag du Microsoft Office Open XML, comment dire, je prends des gants, là.

            • [^] # Re: GIL

              Posté par  (site web personnel) . Évalué à 2.

              Bah la FSF ne fait pas autant de manière que toi avec dotGNU. La limite entre "j'exprime ma parano" et "je FUD" est très floue.

              • [^] # Re: GIL

                Posté par  . Évalué à 2.

                > La limite entre "j'exprime ma parano" et "je FUD" est très floue.

                mh là c'est toi l'expert, je ne pratiquais ni l'un ni l'autre.

                • [^] # Re: GIL

                  Posté par  (site web personnel) . Évalué à 2.

                  L'ECMA garantie que les standards peuvent être implémentées par n'importe qui, il n'y a donc pas de frein à implémenter la CLI ou la CLR et donc à utiliser IronPython sans dépendre de .NET.
                  Tu sous-entends le contraire en mettant en doute les qualités de ces organismes en comparant le processus de normalisation d'un autre format qui a attiré les foudres de nombreux linuxiens.
                  Donc oui, soit t'es parano sur tout ce que normalise MS, soit tu cherches délibéremment à FUDer sans argumenter/détailler ta comparaison.

                  • [^] # Re: GIL

                    Posté par  . Évalué à 1.

                    Ce qui est generalement mis en doute dans .NET c'est:

                    1 - toute la partie non ouverte et couverte de brevet.
                    2 - Recemment il y a eu une interview du responsable de C# et .NET et il disait que la prochaine version serait peut etre normalise.

                    Et comme d'hab on va pas revenir sur le fait que l'implementation de mono a toujours une version de retard. Si l'on compare avec Java ou python c'est flagrant la difference de support sur les OS non microsoftiens... Mais c'est vrai c'est pas la faute de Microsoft ils ont que des incapables qui sont pas foutu de programmer sur un vrai OS (Je suis tres ironique naturellement et).

                    • [^] # Re: GIL

                      Posté par  (site web personnel) . Évalué à 3.

                      Ce qui est generalement mis en doute dans .NET c'est
                      Mon propos était justement de dire qu'IronPython ne dépendait pas de .NET. Enfin si un petit peu puisque son implémentation dépend de la partie DLR (Dynamic Language Runtime) non standardisé/normalisé... mais que Microsoft a mis sous licence libre.
                      IronPython marche sous linux aujourd'hui, c'est une réalité, pas la peine de troller sur .NET, c'est pas le propos.

                  • [^] # Re: GIL

                    Posté par  . Évalué à 2.

                    je ne vois pas le rapport entre "parano", "FUD" et ici douter d'organismes de normalisation qui viennent de prouver récemment qu'ils ne sont pas dignes de confiance, ou bien complètement manipulés. ce n'est pas une histoire de "linuxiens" du tout, ni même de Microsoft ici, ce sont des procédures de décision et de vote totalement baffouées, des évènements très mystérieux dans tout plein de pays, pour ne pas parler de corruption.

                    donc bon ces organismes, niveau crédibilité, intégrité, tout ça, ça va plus.

                    ensuite tu me dis que l'ECMA me garantit des trucs, des espèces de droits, que je pourrais implémenter ces standards sans soucis et je devrais leur faire confiance ?

                    • [^] # Re: GIL

                      Posté par  (site web personnel) . Évalué à 3.

                      donc bon ces organismes, niveau crédibilité, intégrité, tout ça, ça va plus.
                      Ok dérivons un peu.
                      L'ISO a perdu de la crédibilité de ton point de vue (et sans doute du point de vue de nombreuses personnes, surtout côté libristes), mais globalement il répond toujours aux attentes de ceux qui l'utilisent : un moyen pour les industriels de mettre en avant une norme pour des raisons purement commerciales (l'interopérabilité peut être un besoin commercial), je sais pas ce que s'imaginaient les bisounours libristes et le pourquoi de l'ODF à l'ISO.
                      Les votants "nationaux" ne sont là que pour protéger les intérêts de leurs industries respectives, d'où les "pressions" et autres "corruptions".
                      Bref l'ISO continue son petit bonhomme de chemin malgré la polémique.

                      Mais franchement dire que ce que garantie l'ECMA en terme de droits doit être mis en doute parcque l'ISO a normalisé un truc qui te plait pas, c'est du FUD pur et simple. Ou alors tu nous fait une belle démonstration argumentée qui prouve tes allégations (à savoir qu'on ne peut pas implémenter la CLR/CLI pour faire tourner IronPython).

        • [^] # Re: GIL

          Posté par  (site web personnel) . Évalué à 4.

          Quand j'écris une dépêche je lis toujours attentivement les commentaires pour y réagir. J'ai passé toute une nuit à écrire cette dépêche. Alors quand je vois vieux troll (Microsoft, ISO, ECMA, FUD, etc.) totalement dénué d'intérêt (c'est du déjà vu, revu et rerevu), je trouve ça vraiment minable.

          C'est une excellente chose qu'il existe différentes implémentations de Python. Si Microsoft (IronPython) ou Sun (Jython) sponsporise la sienne pour que Python s'intègre mieux à leurs environnement (resp. .NET et Java), je trouve ça bien. D'une manière ou d'une autre, ils contribuent à Python (ex: ça permet à plus de gens d'utiliser Python). Si la licence ne vous plait pas, passez-vous en ou recodez votre implémentation. Pour IronPython, je suppose que ça fonctionne sur Mono. Si ce n'est pas le cas, patchez Mono plutôt que de nous faire perdre du temps.

      • [^] # Re: GIL

        Posté par  (site web personnel) . Évalué à 3.

        IronPython n'utilise pas de GIL ? Si c'est vrai, c'est une excellente nouvelle. PyPy utilise encore le GIL. On voit là l'intérêt d'avoir plusieurs implémentations différentes de Python, chacune a ses qualités et ses défauts : CPython, IronPython, Jython, PyPy, etc. (tiens, et Python pour Parrot ça en est où ?)

  • # 2to3 … nostalgie … ou pas

    Posté par  . Évalué à 3.

    From two to two to two two [http://www.paroles.net/chanson/15269.1] ... salut Boby :)

    Je devrais aller prendre l'air moi je crois …

    PS: Sinon pitié ramenez pas les 2be3 sous prétexte que ça ressemble plus hein.

  • # docs HS

    Posté par  (site web personnel) . Évalué à 2.

    Ce qui explique que la doc de python était innaccessible depuis ce matin ! Et là, elle vient de changer, c'est tout nouveau tout beau, juste un peu lent :o)

    Content de retrouver la doc, je commençais à ramer :)

    • [^] # Re: docs HS

      Posté par  (site web personnel) . Évalué à 2.

      Tu peux consulter la documentation en local en l'installant chez toi. Exemple pour Debian / Ubuntu : « apt-get install python2.5-doc ». Oui, il y a eu un petit clash pour la màj de la doc sur python.org. C'est corrigé maintenant.

  • # python 3.0

    Posté par  . Évalué à 2.

    J'étais encore mitigé sur python 3.0, mais après avoir testé les bytes/string/unicode pour voir si c'était possible de porter mercurial, je suis relativement déçu.

    En effet c'est un énorme merdier la gestion des noms de fichiers. Étant donné que sous linux c'est fondamentalement des bytes, pourtant la plupart des fonctions os renvoient des strings (donc unicode). En fait actuellement c'est encore plus le bordel vu que ça peut renvoyer un mélange de bytes et de str. Par contre sous windows c'est de l'unicode derriere.

    Franchement je vois pas quelle solution peut marcher, pour mercurial on a besoin d'avoir des listes de fichiers de façon indépendante de l'OS et du charset, c'est pas trop possible...

    Voir http://bugs.python.org/issue3187 pour le bugreport.

    • [^] # Re: python 3.0

      Posté par  (site web personnel) . Évalué à 4.

      Je suis en partie à l'origine de ce merdier :-) J'ai écrit le document suivant pour faire l'état de Python3 :
      http://wiki.python.org/moin/Python3UnicodeDecodeError

      En gros :
      - Sous Windows n'utilisez que des chaînes Unicode
      - Sous Linux et BSD (Mac OS X est un BSD) utilisez de l'Unicode si vous êtes fainéants (et vous avez raison ! « Sois fainéant, sois fainéant, tu vivras longtemps ! » chantait Coluche). Si vous voulez vraiment gérer les cas de merde (fichiers encodés n'importe comment, machine mal configurée), utilisez le type bytes (et des fonctions comme os.getcwdb()).

      Pour info, svn refuse les fichiers dont le nom est encodé n'importe comment :
      $ svn stat
      (rien)
      $ touch $(echo -e "oups\xff")
      $ svn stat
      (hex: 6f 75 70 73)
      suivies par une séquence UTF-8 invalide
      (hex: ff)

      J'ai écrit un patch pour Python3 qui a été appliqué hier qui permet d'utiliser des noms de fichier sous forme de chaînes d'octets.

      Finalement, Python3 simplifie le bordel car il passe TOUT en unicode (par défaut). Ce n'est que si vous voulez absolument gérer les cas de merde, que -comme dans tout langage- vous allez avoir des soucis en mélangeant octets et caractères.

      http://www.paroles.net/chanson/22017.1

      • [^] # Re: python 3.0

        Posté par  . Évalué à 3.

        En pratique pour les VCS et les outils de backup c'est la merde pour être multi-plateforme du coup. Sur mercurial les chemins de fichiers ne sont limités que par les limitations de unix (ou de la plateforme pour le checkout, on peut enregistrer des fichiers qui ne peuvent être checkouté que sous ext3).

        Je pense quand même que le coup des bytes est par forcement une amélioration (surtout le fait de passer la gestion de fichier en unicode, je vois pas comment ça peut marcher sous Unix, sauf si on décide que tout le monde utilise UTF-8 en locale, et même comme ça ça doit être possible de créer un fichier qui fera planter python, ou mal fonctionner un programme parce que le dev aura pas pensé à ce cas particulier et utilisera l'API unicode), en pratique ça complique beaucoup le code pour nous (j'espere juste que ça s'améliorera).

        Merci pour tes patches et ta volonté de faire avancer python sur ce problème.

        • [^] # Re: python 3.0

          Posté par  (site web personnel) . Évalué à 2.

          Je pense quand même que le coup des bytes n'est pas forcement une amélioration

          Python2 et la grand majorité des langages de programmations n'utilisent que des octets, même s'ils nous mentent en utilisant des noms comme « char » (character) en C ou « str » (string) en Python. Bien qu'en Python2, on peut travailler en unicode, mais il faut le faire explicitement en utilisant le préfixe « u » (u'unicode').

          En pratique pour les VCS et les outils de backup c'est la merde pour être multi-plateforme du coup.

          Un outil de backup utilisera le type bytes sous Linux, et unicode (str) sous Windows. Les outils de backup représente qu'un faible pourcentage des applications. Les autres utiliseront unicode à tous les étages, ce qui simplifie énormément de choses (évite les horribles problèmes de mélange de charset).

          sauf si on décide que tout le monde utilise UTF-8 en locale

          C'est quand même de plus en plus le cas : UTF-8 est la locale par défaut sous Debian, Ubuntu, Mac OS X, etc.

          Je pense qu'on préfère rester compatible avec les systèmes qui ne parlent pas correctement Unicode (autorisent les chaînes mal encodées) parce que c'est plus facile (zéro effort) que de corriger le problème à la source (d'où vient cette chaîne pourrie ?). Pourquoi ne pas renommer correctement le fichier une fois pour toute plutôt que de devoir corriger tous les programmes pour gérer ce cas pourri ?

          • [^] # Re: python 3.0

            Posté par  . Évalué à 3.

            Je pense qu'on préfère rester compatible avec les systèmes qui ne parlent pas correctement Unicode (autorisent les chaînes mal encodées) parce que c'est plus facile (zéro effort) que de corriger le problème à la source (d'où vient cette chaîne pourrie ?). Pourquoi ne pas renommer correctement le fichier une fois pour toute plutôt que de devoir corriger tous les programmes pour gérer ce cas pourri ?

            Sauf que dans ce cas c'est POSIX qu'il faut changer (rendre unicode obligatoire pour les noms de fichiers, et changer les systèmes de fichiers en conséquence), pour unix les noms de fichiers sont des octets.

            Sinon à mon avis il faudrait unifier les deux API (win et linux) et par exemple toujours convertir les chaînes unicode en UTF-8 sous windows quand on utilise l'API bytes, ainsi le code pour open() sous windows décoderait à partir de l'utf-8 quand on lui passe des bytes.

            • [^] # Re: python 3.0

              Posté par  (site web personnel) . Évalué à 3.

              À mon avis il faudrait unifier Windows et Linux.

              Si tu veux polémiquer sur Python3, utilise plutôt la liste python-3000 et relit les long threads récent sur les noms de fichier unicode ou pas.

          • [^] # Re: python 3.0

            Posté par  . Évalué à 1.

            J'utilise UTF-8 tous les jours, mais je trouve aussi un peu génant de partir du principe que comme "c'est la conf par défaut sur certaines distributions", on oblige les gens à utiliser ça

            Où est le problème à avoir 2 versions ? Pour faire ça, les MFC (entre autres) permettent d'utiliser des LCHAR qui sont des char quand l'unicode n'est pas activé, et des wchar_t sinon.

            Alors forcément, en python il n'y a pas de préprocesseur ... mais bon, il doit bien y avoir une solution, non ?

            • [^] # Re: python 3.0

              Posté par  . Évalué à 1.

              J'utilise UTF-8 tous les jours, mais je trouve aussi un peu génant de partir du principe que comme "c'est la conf par défaut sur certaines distributions", on oblige les gens à utiliser ça

              On n'oblige pas les gens à utiliser ça. Quand tu demandes un nom de fichier unicode sur un système Posix, des heuristiques sont utilisées pour découvrir le jeu de caractères en vigueur sur le système. Le problème c'est qu'en pratique chaque filesystem peut avoir un jeu de caractères différent...

              Où est le problème à avoir 2 versions ?

              Le problème c'est que ça t'oblige à avoir deux chemins de code différents dans ton application, selon que le nom de fichier est unicode ou 8 bits. Alors que ce serait beaucoup mieux si la couche IO de la stdlib s'en chargeait.

              • [^] # Re: python 3.0

                Posté par  . Évalué à 2.

                Le problème c'est qu'en pratique chaque filesystem peut avoir un jeu de caractères différent...

                Même chaque fichier, un cas très courant c'est 2 utilisateurs sur un même filsystem avec des locales différentes.

                • [^] # Re: python 3.0

                  Posté par  . Évalué à 3.

                  Je voudrais pas dire, mais tous ces problèmes, ça n'est pas du ressort de python de les gérer. C'est pas comme si c'était pour s'adapter à une situation un petit peu problématique : là, c'est _vraiment_ le foutoir quand le système n'est même pas bien configuré pour avoir une locale uniforme. Mount propose toujours des options pour indiquer l'encodage des noms de fichiers, pour tous les FS. Si des noms de fichiers utilisent différents encodings dans le même filesystem, python n'y peut rien magiquement ...

                  • [^] # Re: python 3.0

                    Posté par  . Évalué à 1.

                    Il peut donc ne rien faire et considérer les noms de fichiers comme une suite de bytes, comme tout les programmes UNIX.

                    • [^] # Re: python 3.0

                      Posté par  (site web personnel) . Évalué à 3.

                      J'ai patché Python3 pour pouvoir gérer des noms de fichier sous forme de chaîne de caractères. Il suffit d'utiliser le type bytes (ex: b'pouet' au lieu de 'pouet') et les bonnes fonctions (ex: os.getcwdb() au lieu de os.getcwd()).

Suivre le flux des commentaires

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