Sortie de Python 2.4

Posté par  (site web personnel) . Modéré par Florent Zara.
Étiquettes :
0
30
nov.
2004
Python
La version finale de Python 2.4 est sortie aujourd'hui le 30 novembre 2004. C'est une version finale et stable et il est recommandé aux utilisateurs de Python de se mettre à jour vers cette version.

Python 2.4 est le résultat de quasiment 18 mois de développements sur la base de la version 2.3 et représente une nouvelle étape dans l'évolution du langage. Les nouvelles fonctionnalités ont été gardées à leur strict minimum, des bogues ont été corrigés et des améliorations ont été apportées.

Les changements notables dans Python 2.4 incluent une amélioration de l'importation des modules, des décorateurs de fonctions/méthodes et des générateurs d'expressions.

Aller plus loin

  • # enfin....

    Posté par  . Évalué à -9.

    une bonne nouvelle.

  • # Décorateurs

    Posté par  . Évalué à 2.

    Je trouve cette technique très élégante...est-ce que ça a été repompé à un autre langage ?

    En tout cas, cela ajoute un certain contrôle des types dont l'abscence rebutait quelques uns

    • [^] # Re: Décorateurs

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

      Non, non. Enfin, ça permet plein de trucs, mais ça n'ajoute rien, à part un peu de sucre syntaxique. Ce n'est jamais que l'application d'une fonction "enrobante", ce qui était déjà possible. Avant, sans décorateurs: 
      class C:
    def m(x):
        pass
    m = staticmethod(m)
      Maintenant, avec décorateurs: 
      class C:
    @staticmethod
    def m(x):
        pass
      Évidemment, on peut (et on pouvait déjà, la syntaxe en moins) faire bien d'autres choses qu'un contrôle de type, avec les décorateurs. Voir http://www.python.org/moin/PythonDecoratorLibrary(...) pour quelques exemples.

    • [^] # Re: Décorateurs

      Posté par  . Évalué à 4.

      Disons que ça ressemble beaucoup aux metadata de Java2 1.5 ^^ Du moins pour la syntaxe. J'ai regardé un peu comment utiliser les décorateurs et c'est vraiment sympa. On peut *enfin* déclarer des membres statique de manière lisible.

      • [^] # Re: Décorateurs

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

        Oui, en effet, cela ressemble au meta data de Java...
        On pouvait déja faire ça avec XDoclet. Cela permettait d'ajouter du code qui générait le source ou la config manquante.

        C'est très pratique !

        http://about.me/straumat

    • [^] # Re: Décorateurs

      Posté par  . Évalué à 1.

      Le Décorateur est un design pattern assez ancien.

      On peut l'utiliser dans tous les langages OO, mais j'ignore si d'autres langages l'utilisent directement.
      Mais il me semble que java ainsi que .NET font une utilisation très poussée (parfois un peu trop) des design patterns de manière générale.

      • [^] # Re: Décorateurs

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

        Il est clair que la liste des patterns de theserverside par exemple est un peu trop importante... on peut s'en sortir très bien avec 5 ou 6 design patterns...

        http://about.me/straumat

        • [^] # Re: Décorateurs

          Posté par  . Évalué à 1.

          Le but des motifs de conception (ouaip, j'utilise un mot français, na) n'est pas d'être utilisés, c'est de servir.
          Mais effectivement, point trop n'en faut.

          • [^] # Re: Décorateurs

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

            Tant qu'à utiliser le terme français, autant utilisé le plus courament rencontré, cad Patron de Conception ;)
            Le but des dp est avant tout d'identifier et mettre un nom à un problème/solution : c'est un excellent moyen pour se faire comprendre d'autres développeurs sans avoir à réexpliquer comme fabriquer une roue.

            • [^] # Re: Décorateurs

              Posté par  . Évalué à 3.

              Ça y est, je le tiens mon troll ! ;o)
              Patron, c'est pas bien. Motif, c'est mieux.

              Je cite un de mes auteurs favoris (moi-même ;o) :

              Patron est en fait l'étymon de pattern, il a un sens très proche de gabarit, mais il a un second sens en français, celui de «dirigeant», qui peut créer une équivoque, une ambiguïté. Motif est la traduction usuelle de pattern en informatique : pour les expressions régulières, le traitement automatique de texte, etc.

              Motif porte à la fois le sens de figure, forme, répétée et celui de raison, motivation. Or l'utilisation du terme motif dans le contexte du génie logiciel ne permet pas de distinguer clairement laquelle des deux acceptions fait le plus de sens ; il est en effet autant probable que l'on parle de répétitions ou de formes abstraites, modèles de plusieurs formes concrètes, que de motivations, mobiles, d'utilisations de techniques, de concepts ou de modèles d'ingénierie.

              Toutefois, -- et contrairement à celui de patron --, le second sens de motif (raison, mobile) n'est pas antinomique de la définition de nos motifs : comme nous le verrons plus en profondeur, ceux-ci sont une motivation, une raison, de leur propre application et des concepts qu'ils véhiculent. Motif nous semble donc un meilleur choix comme équivalent {Ou un peu plus, grâce à la notion de motivation que le terme anglais ne porte pas.} du terme de pattern.

              [... ici figure une petite recherche sur google que je ne retape pas ...]

              Toutefois, l'on peut remarquer que l'utilisation de l'expression en anglais est fortement majoritaire ; la traduction n'est donc pas encore figée. C'est pourquoi nous avons décidé d'essayer de faire basculer l'usage vers l'utilisation de «motif de conception» comme traduction de design pattern.

              On n'utilise pas les motifs juste pour les utiliser mais parce qu'ils servent, ils sont motivés.

              • [^] # Re: Décorateurs

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

                pour les expressions régulières

                c'est "expression rationnelle" en français

              • [^] # Re: Décorateurs

                Posté par  . Évalué à 2.

                Entre motif et patron je vote "motif" qui est plus proche du sens recherché.
                Et pourquoi pas : Modèle de conception.

                • [^] # Re: Décorateurs

                  Posté par  . Évalué à 2.

                  Dans le texte original, j'avais aussi discuté modèle et gabarit mais modèle est vraiment utilisé à beaucoup trop de sauces. Quant à gabarit, c'est la traduction exacte de template (terme de construction navale : pièce de bois qui sert à en produire d'autres).

              • [^] # Re: Décorateurs

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

                J'ai pris soin de préciser que Patron était la traduction la plus répendu et non la plus adéquate. Hors le but d'un DP est de communiquer un concept avec des termes que tous le monde utilise, donc même si ce n'est pas la meilleiur traduction, Patron de Conception reste le plus approprié à l'heure actuelle ;)

                • [^] # Re: Décorateurs

                  Posté par  . Évalué à 2.

                  Oui mais non. Je n'ai pas remis les résultats de la recherche google parce qu'obsolètes maintenant (18 mois) mais on peut la refaire :

                  recherche sur les pages francophones des chaînes (mots exacts, pluriel+singulier) :

                  "patron(s) de conception" : 968+464
                  "design pattern(s)" : 31100+7700

                  Ok, ce n'est pas une recherche linguistiquement bien faite mais ça donne un aperçu : personne ne traduit (1 sur 27). Alors je m'accroche à faire changer ça pendant qu'il est encore temps.

                  Allons-y Sancho. Sus aux géants !

              • [^] # Re: Décorateurs

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

                > pour les expressions régulières,

                Tu veux dire les expression rationnelles ?
                (moi aussi je sais troller sur le français ;)

              • [^] # Re: Décorateurs

                Posté par  . Évalué à 1.

                C'est ce genre de troll qui fait que tout le monde utilise les termes anglais.

                Au passage, un motif c'est un petit dessin.

                Modèle de conception si on veut bien faire comprendre que l'on vient de France, mais sinon, Design pattern me semble le plus approprié. (Cette dénomination ayant le même avantage que leur objectif : quand on dit design pattern, tout le monde sait de quoi on parle et on a pas besoin de réinventer la roue, alors que patron, motif, modèle de conception,... Faut chaque fois réexpliquer que l'on parle des design patterns)

  • # le python c'est bon

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

    Bon, j'aime beaucoup ce langage. Simple, rapide a aprrendre, une lib de base tres tres complete permettant de faire a peu pres n'importe quoi.

    Sa faiblesse vient a mon avis de son caractere hautement dynamique, qui l'autorise malheureusement a laisser des exceptions dans des coins tres sournois, qui ne seront peut-tres jamais mise en evidence durant les tests mais finiront par se lever en prod dans des condeitions bizarres.

    Des outils comme pychecker ou peak aident a gerer ce genre de probleme mais je ne suis pas encore satisfait des limitations restantes.

    Je reve d'un module qui aurait la force du compilateur de ocaml pour extraire l'ensemble des contraintes appliquees a chaque variable et qui en retirerait des erreurs, un peu comme ce qu'on a a la compile en C++.

    • [^] # Re: le python c'est bon

      Posté par  . Évalué à 4.

      Là tu marques un point. Je fais encore des cauchemars en pensant à des erreurs levées pendant l'exécution du programme final parce que les tests n'avaient pas couvert 100% du code.

      • [^] # Re: le python c'est bon

        Posté par  . Évalué à 1.

        Romain,
        ces erreurs aurait-elles pu être prévenues par des tests unitaires ? Peux-tu nous donner plus de précisions ?

        • [^] # Re: le python c'est bon

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

          ces erreurs aurait-elles pu être prévenues par des tests unitaires

          Pas toujours.
          En fait, à peu près tout est dynamique en python (les exceptions qui me viennent à l'esprit sont les types built-in).
          Ca veut dire que tu peux, durant l'exécution, ajouter ou retirer des méthodes à une instance, ou à une classe, tu peux modifier l'arbre d'héritage d'une classe, etc.

          Tout ceci signifie que l'interface de tes objets peut changer durant l'exécution, ce qui est parfois très pratique pour faire un système de plugins.

          Ajoute à ceci la possibilité de jouer avec les métaclasses (le type de ta classe, pas le type de ses instances), et un accès aux constructeurs eux-mêmes[1], et tu peux te retrouver devant de vrais casse-têtes.

          Je ne dis pas que c'est une bonne ou une mauvaise manière de programmer, juste qu'il y a beaucoup de champ libre et de possibilités de tester, dans un domaine qui est moins habituel quand on vient du java ou du C++.

          [1] Les méthodes appelées « constructeurs » en C++ ou java sont chargées d'initialiser l'instance (comme __init__ en python). Python remonte encore un cran plus haut et donne accès à la méthode qui retourne l'objet créé. Cela veut dire qu'on peut très bien avoir une classe C dont le constructeur (__new__) renvoie en fait une instance de D, même si C et D n'ont strictement rien en commun.

          • [^] # Re: le python c'est bon

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

            A vrai dire je me pose une question :
            Quel est l'intérêt de s'amuser à modifier une classe dynamiquement ? (cad d'y ajouter des attributs, des méthodes, etc.)
            Un exemple d'utilisation concrête ?

            • [^] # Re: le python c'est bon

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

              Zope l'utilise pour ajouter à tout type d'objet des attributs de sécurité (pour savoir quel utilisateur peut ou pas appeler une méthode).

            • [^] # Re: le python c'est bon

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

              Tu peux faire des trucs du type:

              if KDE_SUPPORTED:
              XMainWindow = KMainWindow
              else:
              XMainWidow = QMainWindow


              class MyMainWindow( XMainWindow ):
              ....


              En fait, ces possibilites tres dynamiques ne sont pas tant un besoin qu'une possibilite naturelle offerte par le langage.

              Les methodes d'une classe sont stockees par exemple dans un dictionnaire attache a la classe, dictionnaire que tu peux manipuler a ta guise. Quel interet de les stocker dans un dictionnaire ? Il fallait bien les stocker quelque part. Quel interet de rendre le dictioninaire accessible ? Ben ca peut s'averer pratique dans certains cas mais Guido n'a pas vu de bonne raison de ne pas le faire.

              Par exemple, tu peux faire beaucoup d'introspection en python en passant justement par ce dictionnaire. Alors que en C++, c'est particulierement lourd a faire. Meme en Java ou en .NET, l'api d'introspection est beaucoup plus limitee.

              Les caracteristiques hautement dynamiques de python le rendent vraiment adapte pour faire des trucs un peu tordus ou des trucs complexes. Par exemple, la programmation oriente Aspect est hyper facile a mettre en place en python.

              Mais faut pas croire que parce que il y a des super fonctionnalites, on doit les utiliser. Perso, je n'utilise que les fonctionnalites de base, je me sert de python comme d'un C++ leger et rapide, avec beaucoup de types de bases tres elabores et une large bibliotheque de fonctions.

              • [^] # Re: le python c'est bon

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

                Pour l'introspection je vois bien l'intérêt, pour la programmation orientée aspect aussi, même si dans la plupart des cas on cherche avant tout à générer du code "interne", non visible de l'extérieur, et donc pas des propriétés ou méthodes publiques.
                Mais le fait de pouvoir modifier une classe dynamiquement je ne vois toujours pas :) Quel intérêt y a t-il à tout à coup ajouter des méthodes à un objet, lui ajouter des propriétés ?
                Je comprends bien que le langage facilite ces manipulations mais quel est l'intérêt de pouvori le faire dynamiquement ? (vu tous les problèmes que celà semble poser)

                • [^] # Re: le python c'est bon

                  Posté par  . Évalué à 3.

                  Mais le fait de pouvoir modifier une classe dynamiquement je ne vois toujours pas :) Quel intérêt y a t-il à tout à coup ajouter des méthodes à un objet, lui ajouter des propriétés ?

                  Tu peux faire un proxy, par exemple pour appeler un objet distant en masquant l'API d'appel (XMLRPC, pipe, passage d'événement, etc.). Au premier appel d'une méthode, tu résouds l'appel à la main en générant l'appel vers un wrapper (qui est lui-même une fonction définie à la volée, en général une fermeture), mais au lieu de le regénérer à chaque fois, tu mets en cache le wrapper en question et l'ajoutes aux méthodes du proxy.

                  • [^] # Re: le python c'est bon

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

                    Oué mais un wrapper ca se fait très bien statiquement...

                    • [^] # Re: le python c'est bon

                      Posté par  . Évalué à 6.

                      Oui, mais ça impose de prévoir toutes les méthodes à l'avance : et donc d'écrire une méthode wrappeuse par méthode wrappée.

                      En Python tu peux détecter les appels de méthode inexistantes et créer la méthode wrappante correspondante à la volée. Ainsi ton proxy fait dix lignes une fois pour toutes au lieu de grandir à chaque nouvelle méthode de l'objet proxyisé. Le bénéfice en souplesse est inestimable.

                      • [^] # Re: le python c'est bon

                        Posté par  . Évalué à 3.

                        c'est d'ailleurs la méthode utilisée par les bindings Qt pour Perl et Ruby.
                        Il y a un runtime commun en C++ qui wrappe toutes les méthodes, une interface de requete pour les atteindre, et de tout petits modules Perl et Ruby pour les conversions de types.
                        Avec 13000 méthodes disponibles, 30000 si on wrappe aussi KDE, c'est beaucoup plus simple.

                        • [^] # Re: le python c'est bon

                          Posté par  . Évalué à 4.

                          Le probleme c'est qui ce n'est plus dans l'esprit du langage cible. Par exemple, avoir a utiliser QString en Ruby alors qu'on a une classe String qui est parfaite, c'est pas genial.

                          • [^] # Re: le python c'est bon

                            Posté par  . Évalué à 3.

                            meuh non, on ne wrappe pas _toutes_ les classes sans discernement.
                            Celles qui ont des équivalents natifs Ruby/Perl sont marshallées comme telles (ex. QString <=> chaine native, QStringList <=> liste native de chaines natives, etc.).

                  • [^] # Re: le python c'est bon

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

                    Ca sert aussi dans le cas de test unitaires pour faire des objets 
moqueurs (www.easymock.org).

Exemple:
def my_communication_protocol( my_interface, data ):
    # call many methods of my_interface
    # depending on the execution of each of them, handle
    # the communication protocol
    # return the result
                    Maintenant, comment on teste un bazar pareil ? J'ai justement eu le probleme recemment ou j'ai du ecrire exactement ce genre de code, une fois en C++ et une fois en python. En C++, j'ai du creer une interface generique, rajouter des methodes virtuelles, passer pas mal de temps a memoriser les echanges et pas mal de temps a tester mon objet de test. En python, c'est 10 fois plus simple. Tu passes un objet mock qui va enregistrer tous les appels qui seront faits sur ton interface et qui peut eventuellement retourner des donnees fictives. Exemple reel tire de mon code de test: # correct data, correct sw my_rd = Mock( { "exchangeApdu": data + sw, "powerOn": [0x3B, 0] } ) sp = ScriptPlayerBase( my_rd ) sp.setUnexpectedRaisesException( 0 ) my_rd.clearCalls() self.assertEquals( sp.send( cmd, sw=sw ), data + sw ) allCalls = my_rd.getAllCalls() self.assertEquals( len(allCalls), 1 ) self.assertEquals( allCalls[0].params[0], cmd ) - my_rd est un objet fictif qui retournera data+sw a la methode exchangeApdu, et la liste [0x3B, 0x00] a la methode powerOn. - je le passe a ScriptPlayerBase en lieu et place d'un objet lecteur reel - j'appelle la methode send sur my_rd. Derriere mon dos, sp va appeler my_rd et recevoir les reponses qu'il attend - je verifie que la reponse est correct de send est correcte - ensuite, je liste tous les appels effectues sur my_rd et je verifie qu'ils sont bien ce qu'ils doivent etre. Les capacites dynamiques de python permettent de faire facilement ce genre de chose. Le code pour la classe Mock fait 80 lignes commentaires et documenation comprise. Pour faire le meme test en utilisant une methode a la EasyMock, on aurait: # correct data, correct sw my_rd = EasyMock() my_rd.record() my_rd.powerOn() my_rd.setReturn( [0x3B, 0 ] ) my_rd.exchangeApdu( cmd ) my_rd.setReturn( data+sw ) my_rd.replay() sp = ScriptPlayerBase( my_rd ) sp.setUnexpectedRaisesException( 0 ) self.assertEquals( sp.send( cmd, sw=sw ), data + sw ) # if something went wrong, an exception would have been raised Malheureusement, personne n'a encore ecrit d'easymock pour python. Mais ca doit bien demander une heure de travail a tout casser.

                    • [^] # Re: le python c'est bon

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

                      Chuis vert, j'ai passe 10 minutes a mettre ce post en forme et tout est nique parce que j'ai appuye sur le mauvais bouton au mauvais moment.

Ca sert aussi dans le cas de test unitaires pour faire des objets 
moqueurs (www.easymock.org).

Exemple:
def my_communication_protocol( my_interface, data ):
    # call many methods of my_interface
    # depending on the execution of each of them, handle
    # the communication protocol
    # return the result

Maintenant, comment on teste un bazar pareil ? J'ai justement eu le 
probleme recemment ou j'ai du ecrire exactement ce genre de code, 
une fois en C++ et une fois en python. 

En C++, j'ai du creer une interface generique, rajouter des 
methodes virtuelles, passer pas mal de temps a memoriser les 
echanges et pas mal de temps a tester mon objet de test. En 
python, c'est 10 fois plus simple. Tu passes un objet mock qui va 
enregistrer tous les appels qui seront faits sur ton interface et qui 
peut eventuellement retourner des donnees fictives. 

Exemple reel tire de mon code de test:
   # correct data, correct sw my_rd = Mock( 
   { "exchangeApdu": data + sw, 
      "powerOn": [0x3B, 0] } ) 
   sp = ScriptPlayerBase( my_rd ) 
   sp.setUnexpectedRaisesException( 0 ) 
   my_rd.clearCalls() 
   self.assertEquals( sp.send( cmd, sw=sw ), data + sw ) 
   allCalls = my_rd.getAllCalls() 
   self.assertEquals( len(allCalls), 1 ) 
   self.assertEquals( allCalls[0].params[0], cmd ) 


- my_rd est un objet fictif qui retournera data+sw a la methode 
exchangeApdu, et la liste [0x3B, 0x00] a la methode powerOn. 
- je le passe a ScriptPlayerBase en lieu et place d'un objet lecteur 
reel 
- j'appelle la methode send sur my_rd. Derriere mon dos, sp va 
appeler my_rd et recevoir les reponses qu'il attend 
- je verifie que la reponse est correct de send est correcte 
- ensuite, je liste tous les appels effectues sur my_rd et je verifie 
qu'ils sont bien ce qu'ils doivent etre. Les capacites dynamiques de 
python permettent de faire facilement ce genre de chose. Le code 
pour la classe Mock fait 80 lignes commentaires et documenation 
comprise. 

Pour faire le meme test en utilisant une methode a la 
EasyMock, on aurait: 
  # correct data, correct sw 
  my_rd = EasyMock() 
  my_rd.record() 
  my_rd.powerOn() 
  my_rd.setReturn( [0x3B, 0 ] ) 
  my_rd.exchangeApdu( cmd ) 
  my_rd.setReturn( data+sw ) 
  my_rd.replay() 
  sp = ScriptPlayerBase( my_rd ) 
  sp.setUnexpectedRaisesException( 0 ) 
  self.assertEquals( sp.send( cmd, sw=sw ), data + sw ) 
  # if something went wrong, an exception would have been raised 

Malheureusement, personne n'a encore ecrit d'easymock pour 
python. Mais ca doit bien demander une heure de travail a tout 
casser.

                • [^] # Re: le python c'est bon

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

                  Hé bien comme indiqué plus haut, par exemple : Zope ajoute des méthodes (et des propriétés) en rapport avec la sécurité à la plupart des objets qui lui passent sous la main. Ça évite que les programmeurs aient à s'en soucier (ce sont souvent de simples utilisateurs dans le cas de Zope), et ça permet de systématiser la politique de sécurité.

                  Par ailleurs, on peut s'en servir pour patcher des objets pas à jour : genre tu es sur un vieux Python, tu ajoutes la méthode qui manque. (Bon, ça reste pas très ordinaire, c'est sûr, mais j'ai vu faire.)

                  • [^] # Re: le python c'est bon

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

                    Vi mais le fait d'ajouter des propriétés de sécurité me fait plutôt dire que celà vient combler une lacune de la plateforme, celà devrait être en natif... Si c'est pour étendre une classe avec des propriétés rien ne vaut les méta-données !

                    genre tu es sur un vieux Python, tu ajoutes la méthode qui manque.
                    Vi mais comme d'hab quel est l'intérêt de le faire dynamiquement plutôt que statiquement.

              • [^] # Re: le python c'est bon

                Posté par  . Évalué à 1.

                Just epour avoir une précision:
                Les methodes d'une classe sont stockees par exemple dans un dictionnaire attache a la classe
                C'est un dictionnaire natif ou c'est une customisation à faire a posteriori?

                Parce que si c'est simplement une possibilité de rajouter à chaque fois, dans un dictionnaire géré par le programme, les noms des méthodes - ça voudrait dire que c'est pas de l'introspection mais une façon d'accéder aux méthodes ; au lieu de chercher les dynamiquement (introspection) , sans a priori savoir quelles elles sont. ça ressemble plus à de l'orienté aspect - comme tu dis plus bas.

                • [^] # Re: le python c'est bon

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

                  Le dictionnaire est natif.

                  >>> liste = [1, 2, 3]

                  >>> dir(liste)
                  ['__add__', '__class__', '__contains__', '__delattr__', '__delitem__', '__delslice__', '__doc__', '__eq__', '__ge__', '__getattribute__', '__getitem__', '__getslice__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmul__', '__setattr__', '__setitem__', '__setslice__', '__str__', 'append', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort']

                  >>> liste.__add__
                  <method-wrapper object at 0x403ee9ac>

                  >>> dir(liste.__add__)
                  ['__call__', '__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__name__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__']

                  >>> # etc...

            • [^] # Re: le python c'est bon

              Posté par  . Évalué à 1.

              Un truc concret ?
              Tu prends un parseur de docs XML (j'ai pas eu le temps de regarder ça en python) en DOM.
              Genre ce fichier XML :
              [racine]
               [test]
                [aa]
                 Contenu
                [/aa]
               [test]
              [/racine]

              Avec la modif dynamique d'une classe, c'est très pratique à parser (style SimpleXml dans PHP5) :
              doc = XMLDoc ("fichier.xml")
              print "Le contenu est " + doc.racine.test.aa.get_content()

              D'accord, sans modif dynamique, c'est facile suffit de l'opérateur [] :
              print "Le contenu est " + doc["racine"]["test"]["aa"].get_content() # note : c'est de l'à peu près :p

              Ou mieux :
              print "Le contenu est " + doc.xpath_content ("/racine/test/aa/")

        • [^] # Re: le python c'est bon

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

          C'est difficile de faire des tests unitaires qui couvrent tout. C'est tres tres facile de faire des tests unitaires en python mais sur mes programmes, malgre la palanquee de test, il y a toujours des cas non testes.

          On peut eventuellement utiliser des outils de couverture de code (valider que les tests unitaires exercent tous les chemins) mais je ne suis pas sur ca suffise.

          Typiquement, comme les type sont dynamiques, je me retrouve souvent a abuser un peu de ca, et ca peut faire mal:

          def f( a ):
          if not type(a) is type([]): a = [ a ]
          # now, treat a as a list

          def g( b ):
          if type(b) is type([]):
          for e in b:
          g(b)

          Dans ces deux cas, g et f acceptent deja deux types d'arguments (a noter pour les pythonistes que g peut s'ecrire plus simplement avec map).

          En fait, je pense que ce n'est pas un bon style de programmation parce que c'est un peu dangereux. C'est avec ce genre de connerie qu'on se retrouve avec des chemins d'execution hyper complexes et qu'on peut lever une exception au mauvais moment.

          • [^] # Re: le python c'est bon

            Posté par  . Évalué à 3. 

            def f( a ):
            
if not type(a) is type([]): a = [ a ]
            
# now, treat a as a list


            En effet, ce genre de traitement est vraiment dangereux. Avec ce genre de "patchage d'arguments" tu n'as aucune idée de ce que fait exactement ton programme. Si par mégarde un argument mal formé parvient à ta fonction, le programme continue comme si de rien n'était et va provoquer une erreur peut-être à l'autre bout de ton code source (si tu as mis des patches de ce genre-là un peu partout). Bon courage pour trouver l'origine de l'erreur dans ce cas-là...

    • [^] # Re: le python c'est bon

      Posté par  . Évalué à 1.

      > Des outils comme pychecker ou peak aident a gerer ce genre de probleme mais je ne suis pas encore satisfait des limitations restantes.

      Je connais pychecker (http://pychecker.sourceforge.net/(...)) qui est vraiment excellent, mais pas peak. Est-ce que c'est ça: http://peak.telecommunity.com/(...) ?

    • [^] # Re: le python c'est bon

      Posté par  . Évalué à 4.

      Si tu veux un langage avec une syntaxe similaire à Python, mais du typage statique contrôlé à la compilation, il y a Boo :
      http://boo.codehaus.org/(...)

      C'est basé sur .Net (tourne sous Mono), et semble relativement rapide.

  • # Maturité

    Posté par  . Évalué à 3.

    Outre la sortie de la version, le peu de changements concernant le langage lui-même est une bonne nouvelle. Cela signifie que le langage a atteint une certaine maturité. Cela lui donne une forme de standard. Les gens devraient être moins réticents à l'utiliser et il est fort à parier que le Python va continuer de plus belle son expansion.

    • [^] # Re: Maturité

      Posté par  . Évalué à 4.

      C'est un des énormes avantages de Python, le langage évolué tout en douceur. J'ai très rarement eu de problèmes en essayant de faire tourner un vieux code.
      Je trouve en plus le principe des PEP vraiment excellent.

  • # Pourquoi tous ces self ?

    Posté par  . Évalué à 2.

    Pourquoi dans les méthode de classe doit on systématiquement indiquer un argument 'self' (ou avec un autre nom) qui représente l'instance alors que l'on pourrait avoir ce mot implicitement reservé à cet usage dans la classe ? C'est très lourd je trouve...

    • [^] # Re: Pourquoi tous ces self ?

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Cela fait partie du karma python:

      Explicit is better than implicit

      Grâce à cela tu sais automatiquement que self (que tu aurais pu appeler me) est l'instance qui possède la méthode.

      Mais si tu veux tout savoir GvR y répond là:

      http://mail.python.org/pipermail/tutor/2004-April/028999.html(...)

    • [^] # Re: Pourquoi tous ces self ?

      Posté par  . Évalué à 1.

      « Explicit is better than implicit »

    • [^] # Re: Pourquoi tous ces self ?

      Posté par  . Évalué à 0.

      J'ai lu les commentaires "Explicit is better than implicit" mais je soupconne que c'est une justification 'a posteriori', cela reflete juste qu'historiquement au debut il n'y avait pas d'objet et cela a été rajouter ensuite..

      Le 'Explicit is better than implicit' est un argument creux: si c'était le cas, on programmerait toujours en assembleur: il n'y a pas plus explicite comme language.

      Bon, c'est comme tout, cela a des avantages et des inconvénients.

      Le seul réel avantage que je connaisse , c'est pour appeler un attribut f sur une liste d'objets, on peut faire facilement un map( f , <liste d'objet>) mais au niveau cout visuel c'est quand même cher payé!

      • [^] # Re: Pourquoi tous ces self ?

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


        J'ai lu les commentaires "Explicit is better than implicit" mais je soupconne que c'est une justification 'a posteriori', cela reflete juste qu'historiquement au debut il n'y avait pas d'objet et cela a été rajouter ensuite..


        C'est tout à fait ça. Guido l'explique dans le lien que je donne dans mon commentaire.


        Le 'Explicit is better than implicit' est un argument creux: si c'était le cas, on programmerait toujours en assembleur: il n'y a pas plus explicite comme language.


        Le fait de chercher à ne rien cacher de ce qu'il se passe est au contraire une grande force de python. D'ailleurs, les décorateurs sont un peu à côté de la plaque à ce niveau là, je ne trouve pas qu'ils soient franchement très parlant. Pas mal de syntaxes différentes ont été proposées et celle choisie n'est pas (à mon avis) la meilleure.

        J'aurai largement préférer un truc tel que

        
class A(object):
        
   memoize:
        
         def fact(...):
        
               .........
        
          def tralala(...):
        
                .........


        qui a l'avantage de ne pas introduire un nouveau symbole, de bien montrer la subordination des méthodes à un décorateur et qui n'oblige pas à répéter le même décorateur pour toutes les fonctions. Mais bon c'est GvR qui a le dernier mot et puis il faut voir à l'usage, peut-être que je préférerai ce choix là dans un an.

        • [^] # Re: Pourquoi tous ces self ?

          Posté par  . Évalué à 2.

          >Le fait de chercher à ne rien cacher de ce qu'il se passe est au contraire une grande force de python.

          Oui, mais ce n'est pas appliqué partout autrement python serait de l'assembleur, un bon contre exemple est l'unification des int et des long int en python.. Pour l'appel de fonction, ce principe la aurait put s'appliquer ou pas, il l'a été mais bof..

          Pour ce qui est des décorateurs, j'avoue ne pas comprendre ce que c'est ni à quoi ça sert, quelqu'un aurait-il une URL qui explique cela de façon claire? J'ai déja essayer de lire le PEP, mais sans succes..

      • [^] # Re: Pourquoi tous ces self ?

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

        << Le 'Explicit is better than implicit' est un argument creux: si c'était le cas, on programmerait toujours en assembleur: il n'y a pas plus explicite comme language. >>

        Au contraire, l'assembleur est plutot obscur comme langage. Python est d'une clarte limpide a la lecture et ca, ca vaut cher.

        J'avoue que ca me gonflait aussi un peu au debut, maintenant, je m'y suis fait meme si je l'oublie de temps en temps, ou si je le rajoute sur des fonctions qui n'en ont pas besoin.

        Note que ce n'est pas le seul langage qui demande a declarer explicitement l'instance de l'objet. C'est le cas aussi pour lua, il me semble que c'est aussi le cas pour javascript et je suis sur qu'on peut en exhiber un certtain nombre comme ca.

        • [^] # Re: Pourquoi tous ces self ?

          Posté par  . Évalué à 3.

          >Au contraire, l'assembleur est plutot obscur comme langage.

          Tu confonds clareté et explicite/implicite: python est très simple à lire, très claire car il fait des tas d'opérations implicite derriere ton dos: conversion int<-> big_int, ramasse-miette, etc.. qui doivent être fait de maniere explicite en C ou en assembleur..

          Sinon pour le self explicite, c'est assez répandu effectivement sur tout les languages ou les objets ont été rajoutés apres, en surcouche..

          Et je trouve cela tres moche, d'ailleurs je me demande pourquoi ne pas tout simplement avoir 2 mots: def pour définir les methodes (sans le self) et fun pour définir les fonctions..

          • [^] # Re: Pourquoi tous ces self ?

            Posté par  . Évalué à 6.

            Et je trouve cela tres moche, d'ailleurs je me demande pourquoi ne pas tout simplement avoir 2 mots: def pour définir les methodes (sans le self) et fun pour définir les fonctions..

            Parce qu'en Python, une méthode c'est simplement une fonction qui a été ajoutée comme attribut d'une classe ou d'un objet.

            Par exemple si j'ai une classe Carre:

            class Carre(object):
              def __init__(self, cote):
                self.cote = cote

            Je peux définir une fonction aire_carre pour calculer l'aire d'un carré :

            def aire_carre(carre):
              return carre.cote ** 2

            print aire_carre(Carre(5)) # affiche 25

            Et il suffit d'attacher cette fonction à la classe Carre pour en faire une méthode :

            Carre.aire = aire_carre
            print Carre(6).aire() # affiche 36

  • # Et les perfs ?

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

    On dirait que tout le monde à zappé ça : Python 2.4 inclut un bon nombre d'améliorations des performances, détaillées dans l'indispensable http://python.org/dev/doc/devel/whatsnew/whatsnew24.html(...) (beaucoup plus digeste que NEWS.html). Voir notamment le paragraphe 11.1, en bas de http://python.org/dev/doc/devel/whatsnew/node12.html(...)

    Environ 5% plus rapide que Python 2.3, et 35% plus rapide que Python 2.2. Quand même ! Bon, le benchmark utilisé est standard mais pas très représentatif, si vous avez d'autres chiffres, faites passer.

    Je suis impressionné par le travail de Raymond Hettinger, qui me donne l'impression d'être l'accélérateur de Python.

    • [^] # Re: Et les perfs ?

      Posté par  . Évalué à 3.

      Sauf qu'en général, il se fait taper dessus: ses "accélérations" sont (parfois) des hacks, certes très intelligent, mais qui rendent très complexe le code du langage.

      De plus, ces hacks sont propre au CPython et pas toujours facile à rendre / à faire passer aux autres implèmentations (ironpython, jython)

      Enfin, certains vont lui repprocher des accélérations aux détriments de la complexité du langage. (en terme d'utilisation, pas juste le code). Un exemple : le module dequeue pour faire des piles. C'est rapide, mais ca fait un type de base que personne ne va aller chercher, vu que tout le monde va passer par une liste.

      --OPQ

  • # Quel éditeur/IDE pour python ?

    Posté par  . Évalué à 3.

    Quel éditeur et IDE utilisez-vous pour Python ?

Suivre le flux des commentaires

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