Publication de la version 2009Q2 de Unladen Swallow

Posté par . Modéré par tuiu pol.
Tags :
18
15
juil.
2009
Python
Le projet Unladen Swallow qui, pour rappel, vise à accélérer l'interpréteur Python d'un facteur cinq minimum, vient de publier sa version 2009Q2. Le point notable de cette version est que c'est la première à s'appuyer sur LLVM. Toute fonction appelée plus de 10000 fois est convertie en code natif (compilation à la volée). Les autres points importants sont :
  • L'accélération du temps de démarrage ;
  • La corrections de bugs de cPickle (implémentation en C de la bibliothèque de serialisation d'objets pickle) ;
  • Cette version passe les tests de tous les outils et bibliothèques tiers qui servent à évaluer le projet. Ceci inclus tous les tests de non régression de Python, ainsi que plusieurs projets majeurs parmi lesquels Twisted, Django, NumPy et SWIG.


La consommation mémoire a été multipliée par dix, mais la baisse de consommation de ressources mémoire est un chantier pour la prochaine version (2009Q3).

Cette version n'est pas encore prête pour une utilisation en production, mais permet à chacun de voir la progression du projet.
  • # Un début !

    Posté par . Évalué à 10.

    La consommation mémoire a été multipliée par dix

    Java va devoir faire face à un concurrent de plus en plus sérieux !
    • [^] # Re: Un début !

      Posté par . Évalué à 9.

      Mais non, mauvaise langue:
      Ils ont dit que la prochaine version aura pour but de minimiser la consommation mémoire alors que celle-là a pour but de multiplier les perfs par 5.

      La version 2009Q3 aura pour traits:
      - Grâce au travail d'optimisation, la consommation mémoire a été divisée par 5 par rapport à la précédente version!
      - En contrepartie, la vitesse d'exécution a été divisée par 10.
      - L'amélioration de la vitesse d'exécution est en chantier pour la version 2009Q4.
      - Et moi je sors: −−−−−−−−> [ ]
  • # Avantage

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

    salut

    j'ai fait, du C, Java et python

    et j'ai pas compris pourquoi certains vénère tant ce langage...

    afin bon, si ça trouve son public

    www.solutions-norenda.com

    • [^] # Re: Avantage

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

      Je me permets un commentaire vu que:
      - j'aime beaucoup Python
      - j'en fait pas mal en ce moment
      - j'ai programmé 5 ans ou +
      (ou je programme encore) en C, C++, Java, Fortran, Perl, Shell etc...

      A chaque fois que j'ai fait du Python (comme en ce moment) c'était pour prototyper rapidement et éventuellement garder une appli. qui ne nécessite pas de perfo démoniaque (sinon je fait du C/C++ voire Java).

      Eh bien à chaque fois je n'ai pas été déçu et je suis quasiment certain que je n'aurais pas été plus vite en utilisant d'autres langages que je pratique pourtant plus souvent que Python (C, C++ et dans une moindre mesure Java).

      Je pense que le seul truc qui pourrait me faire changer d'avis serait un autre langage interprété et dynamique comme Ruby ou peut-être Groovy [http://groovy.codehaus.org/] mais surement pas un langage compilé comme C/C++/Java

      Le cycle de compilation+exécution est trop pénible et la dynamicité des langages compilés que je connais est trop faible pour faire des choses très dynamiques
      (même avec l'introspection Java).

      Par exemple DTest (Distributed Test) un petit outil qui permet de lancer des exécutables
      sur différentes machines via une connexion SSH et coordonner [de façon sommaire] leur exécution et ainsi que ce qu'ils affichent sur leur sorties standard, une intro là:
      [http://download.savannah.gnu.org/releases-noredirect/tsp/dte(...)]

      Ca fait 1700 lignes de python (dont ~400 de commentaires) et ça m'a pris au total cumulé une quinzaine de jours.

      J'aurai été incapable de faire ça aussi rapidement en C/C++/Java.
      • [^] # Re: Avantage

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

        Bonjour,

        Je me suis mis aussi au python (en venant du C) il y a quelques temps, et je dois dire que je trouve ça pas simple:

        Certes on élimine la compilation, mais ce faisant on perd aussi toute l'habitude qu'on avais de l'environnement : Makefile, messages d'erreur du compilo,...

        En python, il faut tout réapprendre, en particulier, les messages d'erreurs que je trouve d'une confusion extrême. (Il existe un débuggeur ligne par ligne en python ? Un gdb pour python, en fait)

        De plus les problèmes de version/lib sont toujours là ! J'ai passé un temps fou à trouver l'origine d'un message d'erreur obscur, pour m'apercevoir qu'entre python 2.3 et 2.5 la syntaxe d'un truc avais changé et que mon code ne faisait plus ce que je pensais.
        Ce problème est commun a la plupart des langages interprétés, j'ai eu le même type de truc en ruby.

        Et surtout, même si c'est qu'une question d'habitude, il faut re-apprendre toute l'API: A chaque ligne, je suis obligé d'aller voir la doc: Ouvrir un fichier, vérifier les permissions, récupérer un signal.... bref, bien des fois je me suis dis qu'avec le temps que je perdais à faire ça, j'aurais déjà fini depuis longtemps en C.
        Peut-être que ça payera un jour...
        (Et pourtant, les bouquins le python pour les nul et les linux-mag dédiés au sujet traînent partout à la maison)

        Par contre, il faut avouer que en terme de bibliothèque, le langage est bien fourni, les fonction de haut-niveau (comme les dessins ou le numérique) c'est autre chose que le C, c'est là ou je pense gagner du temps sur le long terme.

        voilà, my 2c
        • [^] # Re: Avantage

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

          "En python, il faut tout réapprendre, en particulier, les messages d'erreurs que je trouve d'une confusion extrême. (Il existe un débuggeur ligne par ligne en python ? Un gdb pour python, en fait)"

          pdb par exemple ?

          Perso, quand il faut faire une appli, je passe beaucoup moins de temps à la faire en python qu'en C/C++. Le langage se fait moins sentir et je peux me concentrer sur ce que je veux faire et pas comment je vais pouvoir le faire avec le langage. C'est mon resenti perso.Mais par exemple, je voulais intéragir avec l'API de vimeo pour envoyer des vidéos. En 30min j'avais un premier trucs qui fonctionnait, fait à "la bite et au couteau", sans utiliser de module pour REST & cie. Ben en C, je sais que j'aurais mis plus de temps.
          • [^] # Re: Avantage

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

            Merci à toi et a tous les autres qui m'ont indiqué pdb, c'est ce que je cherchais !

            Je suis bien d'accord que en python, les bibliothèques sont plus haut niveau qu'en C, qu'il y a moins de "fourbi inutile" pour parser les arguments, allouer la mémoire au préalable, vérifier l'environnement, ... etc

            Comme c'est démontré dans un message en-dessous, récupérer le texte d'une page HTML en python se fait en une ligne, alors que même avec curl et libxml, en C.... ca fait plus d'une ligne, quoi.

            Encore faut-il connaître ces librairies (qui n'est jamais tombé sur la lib idéale pour le script que l'on viens juste de terminer...), et s'habituer aux spécificités du langage, qui pour moi reste quand situé entre le C et le perl/bash en terme de simplicité et logique de la syntaxe.
            (Mais mon point de vue est biaisé, car je connais bien le C et très peu le python).

            J'ai tenté un moment le ruby, j'ai eu la même impression....
        • [^] # Re: Avantage

          Posté par . Évalué à 5.

          (Il existe un débuggeur ligne par ligne en python ? Un gdb pour python, en fait)

          oui ça s'appelle pdb (c'est un module).

          L'utilisation courante est d'insérer dans ton code une ligne:
          import pdb; pdb.set_trace()

          Sinon tu peux aussi le lancer avec une traceback (en post-mortem).

          Il y des environnements qui font ça pour toi.
          Dans les framework web (pylons, werkzeug, zope avec pdbdebugmode) c'est avec ça qu'est fait la console de debug en cas d'exception non interceptée.

          en gros pour l'interception automatique ça revient à ça:

          try:
          my_func(...)
          except SystemExit:
          raise # Reraise the system exit exception
          except Exception, error:
          from sys import exc_info
          import pdb
          pdb.post_mortem(exc_info()[2])
          raise


          enfin avec un shell lancé depuis emacs, celui-ci peut reconnaitre l'arrivée sur une ligne pdb et affiche le code source de la frame en cours dans un autre panneau.
        • [^] # Re: Avantage

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

          En python, il faut tout réapprendre, en particulier, les messages d'erreurs que je trouve d'une confusion extrême.

          De quels messages parles-tu ? Si tu parles des exceptions : entre une traceback qui indique exactement où tu es (nom du fichier + numéro de ligne + ligne de code pour chaque fonction de la pile) et "Segmentation fault", j'ai fait mon choix :-)

          ... pour m'apercevoir qu'entre python 2.3 et 2.5 la syntaxe d'un truc avais changé

          Ça m'étonne, l'API standard est quand même hyper stable. Si tu parles de bibliothèques tierces : bah là ça dépend de la bonne volonté de ses mainteneurs. Mais ce problème n'est pas lié au langage effectivement :-)

          il faut re-apprendre toute l'API: A chaque ligne, je suis obligé d'aller voir la doc: Ouvrir un fichier, vérifier les permissions, récupérer un signal....

          Je trouve que l'API Python est très proche de l'API C (stdlib.h, stdio.h, signal.h, etc.). Au début, il faut juste trouver quel module contient telle ou telle fonction. Exemples C => Python :
          * open(), close() => os.open(), os.close()
          * fopen(), fclose() => f=open(); f.close()
          * sigaction(num, func, &oldfunc) => oldfunc = signal.signal(num, func)
          * access(path, mode) => os.access(path, mode)

          Et puis, la doc Python est plus agréable à lire que les manpages C je trouve. http://docs.python.org/library/
          • [^] # Re: Avantage

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

            De quels messages parles-tu ? Si tu parles des exceptions : entre une traceback qui indique exactement où tu es (nom du fichier + numéro de ligne + ligne de code pour chaque fonction de la pile) et "Segmentation fault", j'ai fait mon choix :-)

            Comparons ce qui est comparable...
            En C , je trouve les messages *du compilateur* plus clairs.
            En python, ya pas de compilation (ou du moins, pas à mon niveau de connaissance).

            Ça m'étonne, l'API standard est quand même hyper stable. Si tu parles de bibliothèques tierces : bah là ça dépend de la bonne volonté de ses mainteneurs. Mais ce problème n'est pas lié au langage effectivement :-)

            Voici le diff en question.
            Je précise que la cible est *python 2.3* , et je développe sous python 2.5. (Non, on peux pas upgrader... Le code doit être compatible avec les 2 versions).
            C'est vrais que c'est dans le module pyUnit.


            - self._tests = unittest.TestLoader().loadTestsFromTestCase(CA_TestCase)
            + self._tests = unittest.TestLoader().loadTestsFromTestCase(CA_TestCase)._tests

            def Build(self):
            ret = True

            [...]

            - self._tests = unittest.TestLoader().loadTestsFromTestCase(Cyclictest_TestCase)
            + self._tests = unittest.TestLoader().loadTestsFromTestCase(Cyclictest_TestCase)._tests

            def Build(self):
            ret = True
            print "Compilation of %s..." % self.name



            Je trouve que l'API Python est très proche de l'API C (stdlib.h, stdio.h, signal.h, etc.). Au début, il faut juste trouver quel module contient telle ou telle fonction.

            C'st exactement là-dessus que je perdais un temps fou, a tel point que je me suis fait un post-it avec les modules pour chaque fonction.

            Et puis, la doc Python est plus agréable à lire que les manpages C je trouve.

            Là pour le coup je ne suis pas du tout d'accord ! Pour moi rien de plus rapide de faire man 2 open et tu as , dans le terminal, le ou les .h qu'il faut inclure & la description des arguments.
            La doc python elle est très bien, sauf que quand tu lance une recherche sur open ya 100 réponses ! Il faut déjà savoir quel module que tu cherche. Et c'est sur le net... si t'a pas le net c'est pas pratique (tu peux la télécharger, mais alors tu fait comment pour chercher ?)



            Au final, moi je trouve qu'il y a du pour & du contre dans les 2 langages, et pour moi le python n'est pas l'eldorado de la programmation tel qu'il est parfois présenté...
            • [^] # Re: Avantage

              Posté par . Évalué à 2.

              Je précise que la cible est *python 2.3* , et je développe sous python 2.5. (Non, on peux pas upgrader... Le code doit être compatible avec les 2 versions).


              Si ton code doit tourner sur python 2.3 alors il faut développer avec un 2.3!
              C'est normal que les API évolue et il ne faut pas t'attendre à ce que tout ce que tu développe avec un 2.5 fonctionne sur un 2.3.

              On a parfois le problème au boulot, avec java, on a forcément une version un peu récente par défaut sur nos machines avec d'autres versions à côté pour les développements qui doivent rester compatibles 1.4, mais parfois un des développeurs oublie sur quel JDK il est et on constate plus tard qu'on a des fonctions du 1.5 qui sont utilisées.
              Heureusement maintenant on est passé à retrotranslator qui nous permet quand même d'utiliser les améliorations les plus fondamentales de l'API java 1.5.
        • [^] # Re: Avantage

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

          Réapprendre un nouveau langage nécessite forcément un certain
          de démarrage j'ai trouvé celui de python acceptable.

          Pour le debugger:

          - python inclut le module pdb [http://docs.python.org/library/pdb.html]

          - il existe aussi pydb [http://bashdb.sourceforge.net/pydb/] qui permet l'utilisation de DDD (à vérifier je ne suis pas utilisateur)

          - comme python est interprété, l'interpréteur est déjà en lui-même un outil d'analyse très intéressant

          Pour ce qui est du ré-apprentissage de l'API, ben évidemment ça peut prendre du temps, mais je trouve que ça va assez vite, car la doc de l'API est bonne.
          Ensuite je pense qu'on gagne énormément de temps quand on utilise des API de haut niveau dont l'équivalent en C serait énormément plus verbeux. Par exemple récupérer un fichier sur un serveur en http:
          import httplib

          dlSavannah = httplib.HTTPConnection('download.savannah.gnu.org')
          dlSavannah.request("GET","/releases-noredirect/tsp/dtest/what_is_dtest.pdf")
          response = dlSavannah.getresponse()
          f=open("what_is_dtest.pdf","w")
          f.write(response.read())
          f.close()
          dlSavannah.close()


          Il faudrait évidemment rajouter la gestion des erreurs, mais même comme ça
          écrire l'équivalent en C, bon courage et même si tu prends la lib qui va bien
          (curl [http://curl.haxx.se/libcurl/c/libcurl-tutorial.html] par exemple)
          • [^] # Re: Avantage

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

            quelques-un on parlé que c'est plus rapide à coder en python qu'en C... ça je crois que tous le monde le savait déjà...

            ton exemple de code n'aurait pas été vraiment plus long à coder en java, delphi...

            www.solutions-norenda.com

            • [^] # Re: Avantage

              Posté par . Évalué à 4.

              > ton exemple de code n'aurait pas été vraiment plus long à coder en java
              Prouve le. Mon expérience me prouve le contraire (pour Delphi j’en sais rien, expérience insuffisante ;)).
              • [^] # Re: Avantage

                Posté par . Évalué à 2.

                En java tu peux faire:


                java.io.InputStream is=new java.io.BufferedInputStream(new java.net.URL("http://download.savannah.gnu.org/releases-noredirect/tsp/dte(...)
                try{
                java.io.OutputStream os=new java.io.BufferedOutputStream(new java.io.FileOutputStream("what_is_dtest.pdf"));
                try{
                int c;
                while(c=is.read()>=0){os.write(c);}
                os.flush();
                }finally{fos.close();}
                }finally{is.close();}
                • [^] # Re: Avantage

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

                  Alors là je te remercie pour ton exemple.
                  On voit que Java et Python ont des librairies standards de
                  suffisamment haut niveau pour faire des choses rapidement mais....

                  On voit aussi que tu as un peu triché en essayant de dissimuler
                  le fait que Java est un langage compilé. Ce qui fait
                  que ton programme tel quel ne fonctionne pas alors
                  que tu peux copier/coller mon exemple python et tu verras que
                  ça marche.

                  Dans ton exemple il manque

                  - une classe englobante
                  <code class getIt { ...
                  }

                  au passage si j'appelle la classe d'un nom différent que le nom
                  de fichier ça me compliquera l'exécution....

                  - une méthode
                  public static void main(String[] args)
                  pour cette classe qui permettra l'exécution du programme

                  - des catchs parce que le finally seul ne semble pas plaire à mon compilo java C'est d'ailleurs très bien que Java force la gestion des erreurs mais c'est précisemment ce que j'aime éviter de faire quand je prototype

                  Je rajoutes à ça, qu'il faut:

                  a) compiler javac getIt.java
                  b) executer java getIt

                  Bref Java ET Python sont très expressifs et ont une librairie standard fourni, mais Python est un langage de script plus souple pour prototyper.
                  Résultat un fichier Java d'environ 27 lignes (pour que ça reste lisible)
                  que je dois compiler+exécuter contre un fichier de 10 lignes en python
                  que je peux exécuter tel quel et/ou copier coller dans l'interpréteur.

                  Je persiste, Java c'est très bien mais pour du prototypage ça vaut
                  pas un clou :-)
                  • [^] # Re: Avantage

                    Posté par . Évalué à 2.

                    En effet, je me contentais de donner un exemple de code équivalent au code python (enfin, pas tout à fait équivalent, les try{}finally{} le rendent plus robuste en garantissant la fermeture propre des flux).
                    Mais je considère effectivement que java est plus adapté à des programmes de taille moyenne à grande bien architecturés, pas pour des petits programmes quick and dirty. Pour ce genre de cas je préfère le shell mariné de grep sed awk et autres commandes facilement scriptables ;-)


                    - des catchs parce que le finally seul ne semble pas plaire à mon compilo java C'est d'ailleurs très bien que Java force la gestion des erreurs mais c'est précisemment ce que j'aime éviter de faire quand je prototype


                    Non, soit tu intercepte les exceptions (et tu en fait quelque chose), soit tu déclare que ta méthode peut les lancer, en l'occurrence ton main.
                    • [^] # Re: Avantage

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

                      mes try{}finally{} le rendent plus robuste
                      d'accord avec ça le problème que ça me pose c'est que tu es obligé de les mettre...

                      Pour ce genre de cas je préfère le shell mariné de grep sed awk et autres commandes facilement scriptables ;-)
                      on est sur la même longueur d'onde je monte souvent a sed et shell afin d'arriver plus awk :-).

                      Mais bon, je dois avouer qu'un bon petit script python fait du bon boulot également, ceci avec le coté riche de Java et le côté Quick & Dirty du shell et ses amis scriptables.
                      • [^] # Re: Avantage

                        Posté par . Évalué à 2.


                        > > mes try{}finally{} le rendent plus robuste
                        > d'accord avec ça le problème que ça me pose c'est que tu es obligé de les mettre...

                        Bien sur qu'on est obligé de les mettre, l'interpréteur/compilateur ne peut pas trouver de lui-même quelle est la façon intelligente de le faire. (Dans les cas simple comme ici ce serait possible, mais pas en général)
                • [^] # Re: Avantage

                  Posté par . Évalué à 3.

                  Oui, c’est effectivement comparable en nombre de lignes. Mais tu es obligé ici de:
                  * créer un objet URL et un objet "BufferedInputStream". En python, je gère un seul objet, "session HTTP". "Buffer" ? "Stream" ? Concepts beaucoup trop bas niveau pour ce que je veux faire, morbleu !
                  * De même, pour l’écriture, tu es obligé de créer un FileOutputStream ET un BufferedOutputStream par dessus. Pour la concision, on repassera. Idem pour la clareté et la simplicité. Pour écrire dans un fichier, c’est trois classes donc: OutputStream, BufferedOutputStream et FileOutputStream. Même si c’était aussi concis que python au niveau du nombre de caractères, ça ne l’est pas au niveau de la doc à consulter.
                  * Obligé de te taper une boucle pour faire le transfert. Effectivement, tu fais ça en une seule ligne, mais bon…

                  Ça semble négligeable, dit comme ça. Mais supposons que je veuille en fait remplacer tous les "spam" par des "egg" dans mon texte (oui, supposons que ce soit pas un pdf). En Python, je remplace response.read() par response.read().replace("spam", "egg"). En Java ? Je dois alors m’amuser avec les StreamReader, les convertions byte[]/String… Ajoute une expression régulière, et la différence python/java devient évidente.

                  Et comme l’ont fait remarqué d’autres plus bas, l’api que tu utilises en Java n’est pas du même niveau que celle en python, qui serait urllib2. L’équivalent du code python utiliserait plutôt WebRequest & co. Encore des classes en plus.
                  • [^] # Re: Avantage

                    Posté par . Évalué à 2.

                    * créer un objet URL et un objet "BufferedInputStream". En python, je gère un seul objet, "session HTTP". "Buffer" ? "Stream" ? Concepts beaucoup trop bas niveau pour ce que je veux faire, morbleu !
                    * De même, pour l’écriture, tu es obligé de créer un FileOutputStream ET un BufferedOutputStream par dessus. Pour la concision, on repassera.


                    Non, tu n'es pas obligé, tu peux te contenter de l'InputStream de l'URL et du FileOutputStream, mais c'est plus efficace de bufferiser les IO.

                    Idem pour la clareté et la simplicité. Pour écrire dans un fichier, c’est trois classes donc: OutputStream, BufferedOutputStream et FileOutputStream. Même si c’était aussi concis que python au niveau du nombre de caractères, ça ne l’est pas au niveau de la doc à consulter.

                    L'OutputStream c'est juste parce que c'est la classe de base et que j'ai l'habitude ne ne pas utiliser les sous-classes quand je peux me contenter de la classe parente, tu peux écrire directement BufferedOutputStream si ça te dérange tant que ça d'avoir des noms de classe différents.

                    * Obligé de te taper une boucle pour faire le transfert. Effectivement, tu fais ça en une seule ligne, mais bon…

                    Dans la méthode python cette boucle est sous-entendue. Au boulot dans un projet de relativement grosse taille on a une méthode utilitaire qui fait ça, on lui passe un InputStream et un OutputStream (ou directement des fichiers ou URLs, y a plusieurs variantes) et elle boucle pour copier l'un dans l'autre.

                    Ça semble négligeable, dit comme ça. Mais supposons que je veuille en fait remplacer tous les "spam" par des "egg" dans mon texte (oui, supposons que ce soit pas un pdf). En Python, je remplace response.read() par response.read().replace("spam", "egg"). En Java ? Je dois alors m’amuser avec les StreamReader, les convertions byte[]/String… Ajoute une expression régulière, et la différence python/java devient évidente.

                    Mais donc dans ton exemple tu va charger tout le contenu de ton URL dans une chaîne de caractères pour pouvoir ensuite faire un remplace dessus et puis la réenregistrer, tu va utiliser beaucoup plus de mémoire que nécessaire par rapport à un fonctionnement en streaming.

                    Mais on en revient à ma remarque précédente que java est plutôt fait pour des projets d'une certaine taille et pas pour du quick and dirty.
                    • [^] # Re: Avantage

                      Posté par . Évalué à 2.

                      Mais on en revient à ma remarque précédente que java est plutôt fait pour des projets d'une certaine taille et pas pour du quick and dirty.

                      Au contraire ! Autant passer 5 minutes au lieu de 2 sur un petit programme ce n'est pas gênant, autant passer 5 mois au lieu de 2 sur un gros ça commence à l'être...
                      Pareil pour la taille du code, 5 lignes au lieu de 2 ça ne change pas grand chose, 5000 au lieu de 2000 ça commence à être dirty. 5 go de ram au lieu de 2 etc etc...
                      • [^] # Re: Avantage

                        Posté par . Évalué à 1.

                        Justement, tu fais des proportions qui n'ont pas lieu d'être.
                        L'enrobage syntaxique à la C++ de java fait que des très petits programmes vont faire beaucoup de ligne pour pas grand chose (mais contrairement à python on peut tout mettre sur une seule ligne ;-) )

                        De plus, je préfère écrire quelques lignes de plus et que le code soit plus lisible plutôt que d'avoir un truc super compact qu'il faut relire cinq fois pour comprendre ce qu'il fait. Mais là je pense plutôt à perl.
                        Et python, qui impose syntaxiquement l'indentation m'empêche certaine mise en forme du code qui en améliore la lisibilité (séparer un long appel de fonction sur plusieurs lignes avec indentation variable pour bien identifier des groupes de paramètres par exemple)

                        Et si tu pense qu'on peut faire un projet de taille raisonnable en quick and dirty, je plains ceux qui devront reprendre ton code.
                        • [^] # Re: Avantage

                          Posté par . Évalué à 4.

                          En python, les parenthèses ont priorité sur l'indentation, il est donc tout à fait possible de choisir son indentation au sein d'un appel de fonction, de l'écriture d'une chaine, de tests etc.

                          Par exemple pour effectuer une requête, je fait souvent quelque chose comme ça (des tirets à la place des espaces)

                          query('select mon champ'
                          - - - - - - 'from matable'
                          - - - - - - 'where macondition'
                          - - - - - - 'order by montri',
                          - - - - - - - - - monparam1='cecicela',
                          - - - - - - - - - monparam2='etci')

                          Pourquoi vouloir associer systématiquement quick et dirty ? L'exemple que l'on a cité montre que l'on peut faire plus long et plus sale en même temps ! Effectivement Perl est compact au détriment de la lisibilité, mais ce n'est pas une généralité. En python on a du quick and clean ! Je comprend que ce ne soit pas évident, comme tu dis, en java on a plutôt tendance à en rajouter pour que ce soit plus clair. On a besoin d'un commentaire pour dire que là, attention, on va ouvrir un fichier...

                          En parlant de reprise de code, j'ai réécrit en python toutes les applis que j'avais faites en java et C. Le résultat est simplement un code beaucoup plus concis, plus clair et beaucoup plus facile à maintenir. Mais ce qui est important à noter c'est que j'ai pu garder exactement les même architectures. Globalement les application ont donc conservées ni plus ni moins la même complexité.
                          Par contre, par la suite, le temps gagné sur le code lui-même (ou plutôt plus perdu en saisie, en jonglage avec l'éditeur, en scrolling de l'écran, en tonne de doc à lire...), permet de se concentrer d'avantage sur l'architecture et de l'améliorer. C'est pour cette raison que l'on y gagne d'autant plus sur des applis particulièrement complexes (c'est pas vraiment la taille qui joue sur la maintenance).
                          • [^] # Re: Avantage

                            Posté par . Évalué à 2.

                            En python, les parenthèses ont priorité sur l'indentation, il est donc tout à fait possible de choisir son indentation au sein d'un appel de fonction, de l'écriture d'une chaine, de tests etc.

                            Ah, ça je ne savais pas, merci.
                            (mon expérience de python date déjà de plusieurs années, je me suis concentré sur java pour raison professionnelle)

                            Je comprend que ce ne soit pas évident, comme tu dis, en java on a plutôt tendance à en rajouter pour que ce soit plus clair. On a besoin d'un commentaire pour dire que là, attention, on va ouvrir un fichier...

                            Ça ce sont les programmeurs qui appliquent sans réfléchir les consignes qu'ils ont eu a l'école, et pas que pour les commentaires!
                            On en a eu un comme ça pendant un moment, c'est toujours un petit éclat de rire, suivit d'un long soupir, de devoir reprendre (réécrire) son code.
          • [^] # Re: Avantage

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

            Pff, il est long ton exemple ! En Python 3.1, ton exemple est deux fois plus court (4 lignes contre 8 lignes) :
            from urllib.request import urlopen
            url = 'http://download.savannah.gnu.org/releases-noredirect/tsp/dte(...)
            with urlopen(url) as dlSavannah, open("what_is_dtest.pdf","wb") as f:
            ...f.write(dlSavannah.read())
            Avec le temps, les programmes Python deviennent de plus en plus court :-) Enfin, de plus en plus haut niveau (urllib est un niveau au dessus d'httplib).
        • [^] # Re: Avantage

          Posté par . Évalué à 2.

          (Il existe un débuggeur ligne par ligne en python ? Un gdb pour python, en fait)

          J'utilise Eric4 qui se trouve dans les dépôts de toute les bonnes distributions; c'est un ide avec débogueur graphique qui permet de voire le contenu de toute les variables, entre autre.
        • [^] # Re: Avantage

          Posté par . Évalué à 2.

          Certes on élimine la compilation, mais ce faisant on perd aussi toute l'habitude qu'on avais de l'environnement : Makefile, messages d'erreur du compilo,...

          Ah c'est vrai qu'il y a lieu de regretter les Makefile :-)

          les messages d'erreurs que je trouve d'une confusion extrême

          Du genre ?

          pour m'apercevoir qu'entre python 2.3 et 2.5 la syntaxe d'un truc avais changé

          Heu, quoi exactement ? La syntaxe ne change normalement pas, il y a seulement des ajouts.
  • # Ça me brule les lèvres...

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

    Pourquoi le choix de 10000 ?
    La compilation est elle destinée à rester sur le HD, dans l'arborescence de Python ?
    Quels sont les gains de performance obtenus par rapport à la version stable de Python ?

    Adhérer à l'April, ça vous tente ?

    • [^] # Re: Ça me brule les lèvres...

      Posté par . Évalué à 2.

      10000 est un choix arbitraire pour ne compiler que le code très utilisé et ne pas pénaliser le démarrage et la mémoire.
      La compilation est en temps réel pour être adaptée à l'utilisation en cours, donc en mémoire seulement.
      Les gains actuels sont très faibles, l'important jusque là était surtout qu'il n'y ait pas de régression avec l'utilisation de LLVM. C'est à partir de maintenant que ça va commencer !
  • # Psyco V2

    Posté par . Évalué à 3.

    Psyco vient de sortir. Pour l'instant il n'y a pas encore beaucoup d'info (support des générateurs), mais Christian Tismer, nouveau mainteneur (payé), promet une renaissance du projet !

    http://mail.python.org/pipermail/python-announce-list/2009-J(...)
    • [^] # Re: Psyco V2

      Posté par . Évalué à 3.

      Certains benchmarks montrés à Europython étaient assez bluffants (jusqu'à 100x plus rapide sur un cas particulier). Et Christian Tismer semble assez optimiste pour la suite.
      • [^] # Re: Psyco V2

        Posté par . Évalué à 2.

        Au niveau impressionnant il y a également, shedskin, qui vient de sortir en 0.2 et qui compile (sous certaines conditions) un programme python en c++.
        http://code.google.com/p/shedskin/ sur des petits bout de programme j'ai réussi à obtenir un gain de 2x par rapport à psyco (j'en ferai un petit journal) !
  • # Décharger avaler

    Posté par . Évalué à 1.

    "Unladen Swallow", il n'y a que moi qui trouve cette dénomination tendancieuse ?

    En tout cas on peut leur dire "good job", pour rester dans le ton.
    • [^] # Re: Décharger avaler

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

      Oui, car la traduction française dans ce cas c'est « hirondelle à vide ».

      Et l'on ne comprend cette référence qu'en connaissant, bien sûr, les œuvres des Monty Python, dans le cas présent Sacré Graal.

      Bridgekeeper: What... is the air-speed velocity of an unladen swallow?
      King Arthur: What do you mean? An African or European swallow?
      Bridgekeeper: Huh? I... I don't know that.
      [he is thrown over]
      Bridgekeeper: Auuuuuuuugh.

Suivre le flux des commentaires

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