Python Python 2.7

Posté par (page perso) . Modéré par patrick_g.
Tags : aucun
35
6
juil.
2010
Python
Un peu moins de deux ans après la version 2.6, la fondation Python est heureuse de vous annoncer la publication de la version 2.7. Cette version marque la fin d'une ère, car ça sera la dernière version majeure de la branche Python 2. Justement, Python 2.7 apporte beaucoup de nouveautés qui viennent de Python 3.1 (listées en seconde partie de la dépêche) dans le but de simplifier la migration de Python 2 vers Python 3. La branche 2.7 sera maintenue plus longtemps que les précédentes versions 2.x.

Python est un langage de programmation interprété multi-paradigme. L'interprète standard (CPython) est distribué sous licence PSF (semblable à la licence BSD). CPython est multiplateforme : Windows, Linux, Mac OS X, *BSD, AIX, MS-DOS, OS/2, QNX, etc.
CPython sert de référence pour le langage Python et les autres implémentations : PyPy (écrit en Python), IronPython (plateforme .NET) et Jython (JVM). Ces implémentations ne sont pas aussi à jour que CPython puisque IronPython est compatible avec Python 2.6 tandis que PyPy et Jython sont compatibles 2.5. Liste partielle des nouveautés issues de Python 3.1 :
  • Syntaxe pour les ensembles littéraux : {1, 2, 3} au lieu de set((1, 2, 3))
  • Compréhension de dictionnaire et d'ensemble, exemples : {i: i*2 for i in range(3)} (dictionnaire) et {i*2 for i in range(3)} (ensemble)
  • Possibilité de spécifier plusieurs gestionnaires de contexte avec une seule déclaration with
  • Réimplementation de la bibliothèque io (entrées/sorties) en C pour offrir de meilleures performances. Cette bibliothèque est notamment utile pour accéder à un fichier texte en Unicode.
  • Dictionnaires ordonnés (enfin !) comme décrits dans la PEP 372 : from collections import OrderedDict
  • La méthode format gère la numérotation automatique : '{} {}!'.format('Hello', 'World') donne 'Hello World'!
  • Le formatage des nombres gère les séparateurs de milliers, exemple : '{:,}'.format(10800) donne '10,800'
  • Amélioration de précision lors des conversions chaîne vers flottant et flottant vers chaîne. Pour un flottant, float(repr(x)) donnera toujours x.
  • Nouveau module argparse pour parser la ligne de commande : version améliorée du module optparse
  • Configuration basée sur des dictionnaires pour le module logging
  • Objets memoryview : vue en lecture seule ou lecture-écriture d'un objet binaire (API similaire à celle du type bytes)
  • Type PyCapsule pour l'API C (pour les modules d'extension)
  • Les types int et long gagnent une méthode bit_length() : nombre de bits nécessaires pour représenter la valeur absolue du nombre

Lire What’s New in Python 2.7 pour de meilleures explications et la liste complète des changements.

Avertissements de dépréciation passés sous silence

Il a été décidé que les avertissements de type DeprecationWarning seront maintenant ignorés par défaut. C'est un changement par rapport à 2.6 qui les affiche (une seule fois pour chaque avertissement) par défaut. L'idée est d'éviter de polluer les utilisateurs avec des avertissements qui ne les concernent pas. Si un développeur veut les afficher, il peut ajouter l'option -Wdefault (ou la forme courte, -Wd) à Python, ou bien définir la variable d'environnement PYTHONWARNINGS à "default" (ou juste "d").

Python 3

Bien que Python 3.0 soit sorti peu après la version 2.6, et que la version 3.1 soit sortie entre temps, peu de développeurs ont sauté le pas. Cela s'explique par diverses raisons.
La première est que Python 3 n'apporte que peu de nouvelles fonctionnalités, mais impose de modifier le code source du projet (en plus des modifications de syntaxe réalisées automatiquement par l'outil 2to3).
La seconde est que toutes les bibliothèques majeures ne sont pas encore disponibles pour Python3. Exemple : PyQt l'est, alors que pygtk est uniquement compatible Python 2.
Enfin, du point de vue des développeurs de Python : il y avait deux branches dans lesquelles les nouvelles fonctionnalités étaient ajoutées (2.7 et 3.2), en plus des deux branches de maintenance (2.6 et 3.1). La plupart du temps, chaque commit devait être répliqué dans les 4 branches, ce qui a un coût non négligeable (bien qu'une partie soit automatisée) car le code de chaque branche a plus ou moins divergé (le pire étant les branches Python 2 et Python 3 justement).

Maintenant les nouvelles fonctionnalités seront développées uniquement dans Python 3. Les efforts vont donc se concentrer pour rendre cette branche plus attractive et aider au portage vers Python 3. Vous pouvez déjà consulter la liste des nouveautés de la branche 3.2 qui va grossir peu à peu.
  • # PyGtk/Python3

    Posté par . Évalué à  10 .

    Actuellement, PyGtk est en train d'être réécrit pour reposer sur l'introspection GObject. PyGI et PyGObject supportent déjà Python3, donc ça ne devrait plus trop tarder.
    https://bugzilla.gnome.org/show_bug.cgi?id=615872
    https://bugzilla.gnome.org/show_bug.cgi?id=566641
    • [^] # Re: PyGtk/Python3

      Posté par (page perso) . Évalué à  10 .

      De toute façon, à quoi ça s'est de s'acharner sur une librairie antique et mal foutue alors que PyQt est tellement mieux et peut en prime prendre l'air moche pour ressembler à du GTK...
      • [^] # Re: PyGtk/Python3

        Posté par (page perso) . Évalué à  4 .

        Le même raisonnement s'applique à Gnome (dont le logo est un pied !).

        Mais bon, la diversité à du bon, tout ça ... C'est juste dommage qu'il n'y ai pas plus de sous derrière KDE.
      • [^] # Re: PyGtk/Python3

        Posté par . Évalué à  5 .

        Bha en fait du GTK c'est pas moche, c'est une question de gôut. Personnellement KDE je trouve ça moche, c'est fait pour les bébé et les enfants.
        • [^] # Re: PyGtk/Python3

          Posté par . Évalué à  3 .

          Exactement. Le thème Clearlooks bien que sobre est relativement esthétique, en tout cas fonctionnel. Après si on cherche des thèmes avec plus de gueule, il y a Murrine, Nodoka et Shiki.

          Alors que sous KDE, à part Oxygen, y'a quoi ? Plastik fait largement plus vieillot que Clearlooks, et il ne reste que CDE, Motif ou Windows 9x...

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: PyGtk/Python3

            Posté par . Évalué à  5 .

            à part Oxygen, y'a quoi ?
            Il y a QtCurve, mais de toute façon il n'y a pas besoin d'autre thème qu'Oxygen, vu sa qualité : je regrette juste Baghira, mais il était de toute façon pénible à configurer (même avec le tuto sous les yeux) .
        • [^] # Re: PyGtk/Python3

          Posté par . Évalué à  10 .

          Personnellement KDE je trouve ça moche, c'est fait pour les bébé et les enfants.
          C'est l'occasion de mettre à jour de KDE 3 vers KDE 4 .
      • [^] # Re: PyGtk/Python3

        Posté par (page perso) . Évalué à  -5 .

        GTK n'est pas antique est mal foutue: elle fait très bien ce qu'on lui demande (dessiner des fenêtres) , et n'est pas moche (ça supporte les thèmes).

        De plus, il y a dedans des choses très utiles comme GTKBuilder, que Qt n'as pas.

        Après c'est sûr tout est relatif: une fois j'ai essayé pyQT4 et ça m'a franchement déplu...
        • [^] # Re: PyGtk/Python3

          Posté par . Évalué à  7 .

          De plus, il y a dedans des choses très utiles comme GTKBuilder, que Qt n'as pas.
          Hoo fud.
          Qt a Qt Designer pour dessiner les fenêtres, et QUILoader pour charger les .ui dynamiquement.

          http://doc.trolltech.com/4.6/quiloader.html

          Au moins Qt a un bon support du buffer souris.
          • [^] # Re: PyGtk/Python3

            Posté par . Évalué à  6 .

            Sans mentionner QML qui arrive avec la 4.7 ... À ce niveau-là, Qt prends de l'avance sur Gtk+ pour la création des IHM dynamiques *et* riches.
          • [^] # Re: PyGtk/Python3

            Posté par (page perso) . Évalué à  1 .

            http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/pyqt4r(...)

            PyQt does not wrap the QUiLoader class but instead includes the uic Python module. Like QUiLoader this module can load .ui files to create a user interface dynamically

            Bon, ok, on peut utiliser le module uic en lieu et place, mais je trouve cela bancal.

            Aussi, je n'ai jamais réussit à enregistrer des "signals/slots" dans qt designer et à les connecter dans python comme je le ferais avec gtk/gtkbuilder/glade


            Au moins Qt a un bon support du buffer souris.


            Si tu parles du fait que l'event mouse-move est floodé sans moyen de contrôle, OUI, ce bug/feature me saoul particulièrement depuis un bout de temps.

            Globalement je préfère gnome par rapport à kde, mais pour les applications graphiques que je développe, je m'en contrefout que cela soit du gtk ou du qt. Les éléments importants pour moi étant la simplicité de développement et la portabilité (+ facilité d'installation).


            A l'époque ou j'avais fait du PyQT, je lui reprochais pleins de trucs, notamment :

            - Une gestion de signal/slots dégueulasse avec PyQT. Je fais du python, je n'ai pas envi de déclarer des prototypes de fonction C++ au milieu de mon code python. Je crois que cela s'est largement amélioré depuis, mais je n'aime toujours pas.
            - Ce problème de Uic cité avant
            - Le fait que Qt impose (c'est pas forcement vrai, mais c'est difficile de sortir du moule) vraiment la façon de penser Qt, l'utilisation de la lib Qt. Gtk ne fait que le toolkit et le fait plutôt pas mal et je n'ai JAMAIS en plusieurs année de pygtk eu a jouer avec la glib.
            - Le fait que cela soit un binding d'un truc en C++ fait avec sip. J'aime pas le C++ ;)

            Par contre il est vrai que pyQt semble vraiment plus portable (par contre il semble que cela soit aussi la misère que pyGtk à installer sous windows), donc c'est un argument qui penchera en sa faveur le jour ou j'aurais un vrai besoin de multi-plateforme.
            • [^] # Re: PyGtk/Python3

              Posté par . Évalué à  3 .

              Ha en fait tu confonds Qt et les bindings Qt pour Python, c'est ça ?

              Je vois pas le problème dont tu parles avec les évènements pour le déplacement de la souris. Moi je parle de la sélection de texte et de ses intéractions foireuses avec le buffer souris sur Gtk : https://linuxfr.org//~mildred/29854.html

              - Le fait que Qt impose (c'est pas forcement vrai, mais c'est difficile de sortir du moule) vraiment la façon de penser Qt, l'utilisation de la lib Qt.
              Tout comme Gtk impose l'utilisation de la glib. Je vois pas le problème.
              • [^] # Re: PyGtk/Python3

                Posté par (page perso) . Évalué à  3 .

                Ha en fait tu confonds Qt et les bindings Qt pour Python, c'est ça ?

                Ha ?

                Non... Je parle de PyQT depuis le départ. Je n'ai jamais fait de C++Qt et je ne veut pas en faire (pour pleins de raisons, la première étant que je trouve stupide de s’embêter avec du C++ pour programmer, à mon humble avis, 99.9% des usages actuels du C++ sont non justifiés). La dépêche parlait de python, et ce fil de commentaire de PyQT/PyGTK, donc il n'y a pas trop de problème à ce que je parle de PyQT.


                Je vois pas le problème dont tu parles avec les évènements pour le déplacement de la souris. Moi je parle de la sélection de texte et de ses intéractions foireuses avec le buffer souris sur Gtk : https://linuxfr.org//~mildred/29854.html


                Ok. Personnellement cela ne m'a jamais posé problème, mais je me sert très peu de la souris. Ce qui me saoul ici avec Gtk c'est que lorsque l'on s’intéresse aux event souris, soit l'on en reçoit une quantité énorme non traitable en temps utile si le traitement prend un peu de temps (genre 100/s) si la souris bouge vite. Soit l'on peut activer le *buffer* (MOTION_HINT_NOTIFY) qui normalement se contente d'envoyer un seul event jusqu'à ce que tu lui dise qu'il peut en envoyer de nouveau, mais pourtant il continue à en envoyer plein.

                Tout comme Gtk impose l'utilisation de la glib. Je vois pas le problème.

                Avec pygtk je n'ai JAMAIS utilisé directement la glib. Je n'ai jamais utilisé la variante de string de la GLib, ni les structures de données de la Glib. A l'époque ou j'avais fais un peu de PyQT, je devais instancier des QString pour faire correctement fonctionner l'unicode et il m'arrivait de devoir charger des QList ou autre.

                Le binding pygtk est vraiment intégré de façon transparente à python. Apparemment c'est mieux pour le binding pyQT pour python3. En résumé je veux bien faire du QtGui, mais pas du QtList, QTString, QTFile, QtTortue.

                Bref, quand python3 sera utilisable pour moi en production (mon attente principale étant numpy) et si quelqu'un me trouve comment faire pour connecter un signal de qt designer sur un slot de mon code, je redonnerais à pyqt sa chance. En attendant, pygtk est bien plus au dessus pour mon besoin à moins en confort de programmation.
                • [^] # Re: PyGtk/Python3

                  Posté par . Évalué à  1 .

                  Non... Je parle de PyQT depuis le départ.
                  Alors n'affirme pas que Qt n'a pas d'équivalent à GTKBuilder, affirme que PyQt ne fait pas bien son boulot en choisissant de ne pas implémenter de bindings pour QUITools…

                  Avec pygtk je n'ai JAMAIS utilisé directement la glib. Je n'ai jamais utilisé la variante de string de la GLib, ni les structures de données de la Glib. A l'époque ou j'avais fais un peu de PyQT, je devais instancier des QString pour faire correctement fonctionner l'unicode et il m'arrivait de devoir charger des QList ou autre.
                  Ce n'est plus le cas sur les dernières versions de PyQt, même en Python 2…

                  Sinon pour ton histoire de signaux et slots je vois pas non plus le problème…

                  Voici un exemple de code :

                  #!/usr/bin/env python
                  # -*- coding: utf-8 -*-

                  from PyQt4 import uic, QtCore, QtGui
                  import sys


                  app = QtGui.QApplication(sys.argv)
                  (f, c) = uic.loadUiType("test.ui")
                  class m(f, c):
                  def machin(self):
                  print "test !"

                  chose = m()
                  chose.setupUi(chose)
                  chose.show()
                  app.exec_()


                  Dans le fichier test.ui j'ai une fenêtre avec un slot machin() défini et connecté au clic sur un bouton… Et ça marche…
                  • [^] # Re: PyGtk/Python3

                    Posté par (page perso) . Évalué à  1 .

                    Alors n'affirme pas que Qt n'a pas d'équivalent à GTKBuilder, affirme que PyQt ne fait pas bien son boulot en choisissant de ne pas implémenter de bindings pour QUITools…

                    Tu dois me confondre avec quelqu'un d'autre. Moi j'ai juste dis que le binding était pourris.

                    Merci pour le code. C'est bizarre (surtout le chose.setupUi(chose), cela me force à faire un héritage ce que je n'aime pas, mais cela à l'air de fonctionner.


                    Ce n'est plus le cas sur les dernières versions de PyQt, même en Python 2…


                    C'est pas ce que j'ai lu dans la doc. Mais cela ne m'empechera pas de restester le jour ou j'aurais à me poser la question (cf le message précedant ou je ne suis vraiment pas beliqueux envers pyQT, juste que à l'époque ou j'ai essayé, cela ne remplissait pas du tout mes besoins)
                    • [^] # Re: PyGtk/Python3

                      Posté par (page perso) . Évalué à  1 .

                      Je me trouve vraiment con depuis 10 minutes sur l'interface de designer à essayer d'ajouter un slot qui n'existe pas sur ma fenêtre. IL ne me propose que des noms de slots qui existent déjà...
                      • [^] # Re: PyGtk/Python3

                        Posté par . Évalué à  3 .

                        Clic droit sur ta fenêtre, Change Signals/slots.
                        T'as alors une liste de slots avec un bouton + en dessous de la liste…
                      • [^] # Re: PyGtk/Python3

                        Posté par (page perso) . Évalué à  2 .

                        Quand j'appuie sur le signe + vert, je peux mettre ce que je veux comme signal ou slot.

                        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                    • [^] # Re: PyGtk/Python3

                      Posté par . Évalué à  2 .

                      Tu dois me confondre avec quelqu'un d'autre. Moi j'ai juste dis que le binding était pourris.
                      Effectivement, mea culpa…

                      Sinon pour le chose.setupUi(chose), c'est un choix dans mon implémentation…
                      J'aurais pu/du créer un QWidget à part et faire chose.setupUi(mon_beau_widget)
                      • [^] # Re: PyGtk/Python3

                        Posté par (page perso) . Évalué à  1 .

                        Merci.

                        Bon, ca marche bien. Faut que je trouve comment se debarasser de cet héritage que je n'apprécie pas trop, mais sinon cela marche bien.
                        • [^] # Re: PyGtk/Python3

                          Posté par . Évalué à  2 .

                          Faut que je trouve comment se debarasser de cet héritage que je n'apprécie pas trop
                          Lequel ?
                          Tu peux n'hériter que de QWidget par exemple et faire ceci :

                          #!/usr/bin/env python
                          # -*- coding: utf-8 -*-

                          from PyQt4 import uic, QtCore, QtGui
                          import sys

                          class myForm(QtGui.QWidget):
                          def machin(self):
                          print "test !"

                          app = QtGui.QApplication(sys.argv)
                          (uiForm, container) = uic.loadUiType("test.ui")
                          chose = myForm()
                          uiGenerator = uiForm()
                          uiGenerator.setupUi(chose)
                          chose.show()
                          app.exec_()


                          Je vois pas pourquoi l'héritage de QWidget serait un problème…
      • [^] # Re: PyGtk/Python3

        Posté par . Évalué à  3 .

        mes 2 cents:
        - en tant qu'utilisateur : QT m'émerve, KDE est mal foutu, et ormis quelques applications, je ne les utilises plus. Trop complexes, mal foutu, moche, inutilisable, complexe. J'aime bien amarok, qtfps, smplayer. Chez moi tout le reste est en gtk. De manière générale, j'évite l'environnement KDE où je préfère la simplicité de gnome
        - en tant que développeur : QT c'est le pied, la courbe d'apprentissage, la doc et le support sont extraordinaire, et je développe que des applications QT.

        Mais alors pourquoi les developpeurs QT ont il tendance à faire toujours des soft trop complexes avec 15 000 panels de configuration, ... Et pourtant, c'est possible de faire de tres belles applications en QT... juste que les développeurs, quand ils voient la simplicité de programmation, compense par une complexité à l'utilisation...

        Au final, je n'utilise que les applications qt qui sont en fait des GUI sur des programmes en ligne de commande.
        • [^] # Re: PyGtk/Python3

          Posté par (page perso) . Évalué à  4 .

          en tant qu'utilisateur : QT m'émerve, KDE est mal foutu,

          Tu parles de Qt ou de KDE?

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: PyGtk/Python3

            Posté par . Évalué à  3 .

            plutot de KDE effectivement.

            Il y a des applications QT extraordinaire (au niveau UI).

            QT est vraiment le pied a programmer (en C++).

            Il y a des applications GTK vraiment pourri (qui a dit GIMP?).

            GTK est vraiment nul à programmer (en C++).

            Mais de manière générale, sous leur environnement de prédilection respectif (KDE et Gnome), je trouve beaucoup plus agréable d'évoluer sous gnome que sous kde. Question de culture du nombre de bouton au metre carré je pense.
            • [^] # Re: PyGtk/Python3

              Posté par (page perso) . Évalué à  -1 .

              Je n'aime pas le rendu de Qt (surtout les polices, la taille des widget, etc)
              Je n'aime pas KDE.
              Qt ne se programme pas en C++. C'est du Qt C++, avec des gros morceaux de pré-processeur partout, et des classes doublons par rapport à la STL (j'en convient, il y a 10 ans il fallait bien proposer ces propres classes pour être portable. Il y a 10 ans).

              Qu'est-ce qui te gêne dans Gtkmm ?
              • [^] # Re: PyGtk/Python3

                Posté par . Évalué à  2 .

                Même maintenant, pour être portable proprement avec certains compilateurs tordus, pour avoir une gestion propre de l'unicode partout, une API "claire" et lisible... il vaut mieux faire des doublons de la STL.
                Également, pour réaliser de l'introspection sans passer par le RTTI, le choix de moc me semble raisonnable.
                Quand tu dis "gros morceaux de pré-processeur partout", je pense d'ailleurs que tu n'as pas vu de code en Qt depuis très longtemps...
                • [^] # Re: PyGtk/Python3

                  Posté par . Évalué à  2 .

                  bah, si il a raison en un sens, il est mieux de passer par moc si on veut utiliser QT à fond (qtdesigner,...)
                  Quant au doublon avec la STL, si tu rajoutes boost, oui effectivement, ça fait VRAIMENT doublon.

                  N'empeche que de l'autre coté, gtk (en C) est vraiment une plaie à programmer. Je ne connais pas gtkmm... néanmoins il m'a l'air méchament lié ) automake, pkgconfig. Ca va pas facilité le portage sous windows ça...
                  Par contre... comment dire...
                  QT : http://doc.trolltech.com/4.6/classes.html
                  GTKmm : http://library.gnome.org/devel/gtkmm/unstable/group__Widgets(...)

                  hum, niveau doc... c'est pas trop ça.
                  • [^] # Re: PyGtk/Python3

                    Posté par . Évalué à  2 .

                    À ma connaissance, Qt est l'une des bibliothèques avec la meilleure documentation qu'il soit... Et vu les domaines couverts par les classes de Qt, c'est nickel quoi (Gtk ne couvre finalement qu'une partie de QtGui, il faut y ajouter la stl pour QtCore, libxml pour QtXml, libwebkit-gtk pour QtWebkit ... et la documentation sur tout ça n'est centralisée nulle part)
  • # Fonctionnalités Python 3.1 -> 2.7

    Posté par (page perso) . Évalué à  8 .

    La première est que Python 3 n'apporte que peu de nouvelles fonctionnalités

    Rien que ta liste partielle des nouveautés issues de Python 3.1 me donnerait envie de switcher si ce n'était déjà fait. À la fois du lourd comme les dictionnaire ordonnées et les compréhension de dictionnaire et ensemble mais aussi du sucre syntaxique qui fait la qualité de la syntaxe du langage Python

    On remarquera également une participation importante de l'auteur de la dépêche à cette nouvelle mouture de Python en lisant le changelog ;)
    • [^] # Re: Fonctionnalités Python 3.1 -> 2.7

      Posté par . Évalué à  2 .

      J'ai aussi fait du python 3 pour des fonctions qui n'étaient pas vraiment clean en python 2 (par ex la manip de binaires, c'est via strings en python 2). Je trouve le 3 plutôt avantageux.

      Par contre la plupart des scripts existant sont en python 2 + flême et "ca marche pas mal déja", ca ca retarde l'adoption de python 3 chez moi :)
    • [^] # Re: Fonctionnalités Python 3.1 -> 2.7

      Posté par . Évalué à  4 .

      Justement, au sujet des dictionnaires ordonnés : en quoi est-ce une bonne fonctionnalité ?

      Disclaimer : je ne suis pas un programmeur Python, donc je n'ai pas en tête les utilisations idiomatiques du langage.

      Je ne comprends pas pourquoi cette fonctionnalité est mise en avant comme quelque chose de tellement bien. Pour moi, un dictionnaire ordonné c'est au mieux une curiosité qui sert une fois par an, au pire une API mutante qui encourage de mauvaises pratiques.


      J'ai suivi le lien pour la PEP (merci pour le lien), et certaines des raisons qui sont données (paraphrasées selon ce que j'en comprends) me laissent un peu perplexe
      - quand on manipule des noeuds XML, on veut stocker les attributs dans un dictionnaire, mais qu'ils restent dans l'ordre : il me semble que d'après la définition de XML, les attributs ne sont pas ordonnés, et qu'il est donc une mauvaise pratique de dépendre de l'ordre des attributs d'un document XML.
      - on veut porter du code depuis PHP qui utilise implicitement le caractère ordonné du dictionnaire : est-ce que le code de départ avait vraiment besoin de l'ordre ? Je comprends l'intérêt de pouvoir porter du code même mal écrit, mais ça fait sourire d'apprendre qu'on va améliorer Python en facilitant l'import de code PHP douteux.


      La PEP cite aussi deux exemples crédibles où une telle structure serait utile (les "struct" de C, dont le layout mémoire dépend de l'ordre, et à la rigueur les noms de colonnes SQL bien qu'on les manipule en général de façon non ordonnée).


      Je ne pense pas que les dictionnaires ordonnés soient à bannir, mais je pense qu'ils ne sont en général pas nécessaires et qu'ils font souvent plus de mal que de bien (cf. l'exemple des attributs XML qui se contente de perpétuer de mauvaises pratiques). Les mettre dans la stdlib, pourquoi pas, mais je suis étonné de tout le bruit que ça fait, et de l'absence de mise en garde à ce sujet.
      • [^] # Re: Fonctionnalités Python 3.1 -> 2.7

        Posté par . Évalué à  3 .

        En Ruby, j'ai utilisé une librairie qui mettait les attributs XML dans un dictionnaire (non ordonné).

        A chaque génération du XML, nous n'avions pas forcément le même XML. Peut-être que d'un point de vue sémantique, les XML étaient identiques mais pour valider les modifications, c'était toujours un peu la galère ...

        Après, c'est peut-être aussi car je n'ai jamais trouvé un outils pour comparer deux XML correctement.
      • [^] # Re: Fonctionnalités Python 3.1 -> 2.7

        Posté par . Évalué à  1 .

        Pense à du XHTML, ou un système de formattage de document, si t'as un ensemble de paragraphe tu veux forcément conserver l'ordre.

        Dans les DTD tu pouvais décrire l'enchainement des sous balises, éventuellement mélangées à du texte, par une regex.
      • [^] # Re: Fonctionnalités Python 3.1 -> 2.7

        Posté par (page perso) . Évalué à  1 .

        Je ne comprends pas pourquoi cette fonctionnalité est mise en avant comme quelque chose de tellement bien. Pour moi, un dictionnaire ordonné c'est au mieux une curiosité qui sert une fois par an, au pire une API mutante qui encourage de mauvaises pratiques.

        Tu peux très bien avoir besoin d'associer aux membres d'un dictionnaire une notion d'ordre sans vouloir passer par un conteneur ordonné classique (tuple, liste) qui va dénaturer ta structure de données en te forçant à utiliser un indice numérique par exemple.

        Si ta remarque signifie "on pouvait s'en passer jusqu'à maintenant", personne ne te contredira. Maintenant l'inclusion de cette nouvelle structure de données te permet une plus grande liberté dans ton travail.
        • [^] # Re: Fonctionnalités Python 3.1 -> 2.7

          Posté par . Évalué à  3 .

          Il me semble qu'OrderedDict ne permet pas d'associer un ordre (choisi par le programmeur) aux clés, mais se contente de conserver l'ordre d'insertion. En tout cas, c'est ce qu'indique la PEP 372 :

          « Does OrderedDict support alternate sort orders such as alphabetical?

          No. Those wanting different sort orders really need to be using another technique. The OrderedDict is all about recording insertion order. If any other order is of interest, then another structure (like an in-memory dbm) is likely a better fit. »

          Je vois quelques cas où on a envie de donner un ordre sur les clés d'une table associative (typiquement, dans les langages où ces tables sont implémentées par des arbres équilibrés, l'implémentation demande déjà un ordre, et propose des fonctions d'itération qui garantissent de parcourir les éléments par ordre croissant des clés par exemple, et je m'en suis déjà servi dans de rares cas).
          J'ai beaucoup plus de mal à trouver un bon exemple (qui soit naturel, et où ce n'est pas juste un hack) où l'ordre voulu est précisément l'ordre d'insertion des éléments. Je ne doute pas que ça existe, mais j'ai l'impression qu'il y a beaucoup de mauvais exemples et peu de bons exemples.

          Qu'est-ce qui te fait dire que c'est "du lourd" ? Tu as des exemples intéressants à nous montrer où tu as senti le besoin de cette structure de données ? Je pense que ce serait une bonne idée d'agrémenter ce changelog un peu brut par une discussion réelle des fonctionnalités : comme je l'ai dit, je pense qu'il serait bon d'avertir les gens des risques de mauvaise utilisation (attributs XML), mais des bons exemples seraient encore plus sympas.
          • [^] # Re: Fonctionnalités Python 3.1 -> 2.7

            Posté par . Évalué à  2 .

            En ce qui concerne Java, l'équivalent d'un dictionnaire ordonné est la classe LinkedHashMap. Et bien c'est bien utile lors de l'écriture de tests unitaires pour son code quand on utilise un dictionnaire (resp. Map) afin d'obtenir un comportement déterministe lors de l'itération sur le dictionnaire ordonné.
            Sorti de ce cas simple, je ne crois pas en avoir eu une vrais utilité ailleurs. Quelqu'un a d'autres exemples?
      • [^] # Re: Fonctionnalités Python 3.1 -> 2.7

        Posté par (page perso) . Évalué à  1 .

        Ave,

        Si tu veux générer un CSV à partir d'un dictionnaire, ça peut être très pertinent.

        Idem pour un ORM avec une construction déclarative du model, tu veux que les attributs SQL soit créés dans l'ordre de déclaration de l'object Python. Cf le code de SQLAlchemy qui numérote les colonnes pour retrouver l'ordre des attributs.

        Étienne
        • [^] # Re: Fonctionnalités Python 3.1 -> 2.7

          Posté par . Évalué à  2 .

          Attention avec l'exemple du CSV : l'ordre d'un OrderedDict est l'ordre d'insertion dans le dictionnaire. Quand tu reçois deux OrderedDict avec les mêmes clés, tu ne peux pas supposer que l'ordre sera le même.

          Python 3.1.2 (r312:79147, Mar 21 2010, 18:30:25)
          [GCC 4.4.3] on linux2
          Type "help", "copyright", "credits" or "license" for more information.
          >>> from collections import OrderedDict
          >>> header = OrderedDict([('a', 'Nom de la colonne A'), ('b', 'Nom de la colonne B')])
          >>> line = OrderedDict()
          >>> line['b'] = 'Valeur pour B'
          >>> line['a'] = 'Valeur pour A'
          >>> for h in header.values(): print(h)
          ...
          Nom de la colonne A
          Nom de la colonne B
          >>> for v in line.values(): print(v)
          ...
          Valeur pour B
          Valeur pour A


          Il me semble qu'il faut repasser par un tri explicite des entrées du dictionnaire / de la liste, dans tous les cas.
      • [^] # Re: Fonctionnalités Python 3.1 -> 2.7

        Posté par . Évalué à  5 .

        L'exemple typique, c'est les fichiers de config (.ini). Sémantiquement c'est un ensemble de clés / valeurs, mais si tu veux générer un .ini qui soit facile à reprendre par l'utilisateur, tu as aussi envie d'écrire les entrées dans un certain ordre.
    • [^] # Re: Fonctionnalités Python 3.1 -> 2.7

      Posté par (page perso) . Évalué à  2 .

      Je viens d'apprendre Python, et j'ai bloqué un moment sur ce faux ami : « comprehensive ». Ce serait mieux d'utiliser un terme français plus approprié, histoire d'éviter les incompréhensions concernant ce terme :D

      Par exemple : comprehensive list → Listes étendues/ensemblistes/complétives ?

      (C'est quand même mieux que le troll à propos de Ruby ^^;)
  • # Scipy ?

    Posté par . Évalué à  4 .

    Bonjour,
    l'un d'entre vous sait-il quand les bibliothèques de calcul numérique et de tracé seront utilisables avec python 3 ?
    Sur le site de Scipy il est vaguement annoncé « milieu de l'année 2010 » sans plus de précision.
    Bye
    • [^] # Re: Scipy ?

      Posté par . Évalué à  4 .

      Pour que Scipy passe à Python 3 il faut que Numpy fasse le pas avant et ça semble prévu pour Numpy 2.

      Python 3 compatibility is planned and is currently technically feasible, since Numpy has been ported. However, since the Python 3 compatible Numpy 1.5 has not been released yet, support for Python 3 in Scipy is not yet included in Scipy 0.8. SciPy 0.9, planned for fall 2010, will very likely include experimental support for Python 3.

      http://projects.scipy.org/scipy/roadmap#python-3
      http://projects.scipy.org/numpy/roadmap
  • # microtrolloire

    Posté par . Évalué à  -5 .

    s/linuxfr\.org/rubyvspython.fr/
    • [^] # Re: microtrolloire

      Posté par (page perso) . Évalué à  3 .

      Pas assez de messages sur le ruby pour l'instant, l'inverse est par contre plus fréquent sur une news du ruby.

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

      • [^] # Re: microtrolloire

        Posté par (page perso) . Évalué à  3 .

        Ces dernières étant plus fréquentes, on peut en conclure que les pythoneux trolle tandis que les rubyistes font du contenu utile.

        ----> []

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: microtrolloire

          Posté par . Évalué à  8 .

          Ou alors que les pythoneux ont déjà terminé leur travail…
    • [^] # Re: microtrolloire

      Posté par (page perso) . Évalué à  3 .

      linuxfr.org est en train d'être réécrit en... Ruby :-)
    • [^] # Re: microtrolloire

      Posté par (page perso) . Évalué à  -2 .

      > s/linuxfr\.org/rubyvspython.fr/

      C'est assez rigolo d'ailleurs vu que tout le monde ici utilise surtout perl ou php comme langage interprété.
      • [^] # Re: microtrolloire

        Posté par (page perso) . Évalué à  0 .

        > tout le monde ici utilise surtout perl ou php comme langage interprété.

        Tout le monde ? Non ! seul quelques moules résistent encore et toujours à l'envahisseur… \o/
  • # D'ailleurs

    Posté par (page perso) . Évalué à  1 .

    On parlait de PySide à une époque, qui n'étais pas compatible avec python 3, ça a changé depuis?

Suivre le flux des commentaires

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