Journal Journal inutile : Python c'est complêtement pourri, j'ai un exemple

Posté par  .
Étiquettes : aucune
-27
1
juin
2010
Avant, en Python on pouvait simplement ouvrir un process comme on ouvre un fichier avec os.popen.

Maintenant, semble-t-il, à partir de python 2.4, ce n'est plus possible.
Il faut passer par le module subprocess. Et la ça m'agace.

http://docs.python.org/library/subprocess.html#replacing-os-(...)

Je ne vois pas trop l'intérêt d'un tel remplacement. Je n'aimais pas trop python comme ça (sans non plus le détester), mais là il baisse encore d'un cran dans mon estime.

Je sais, mon journal est inutil mais je m'en moque. Ca soulage c'est tout (vous étiez prévenu dans le titre).
  • # Avant après

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

    > Avant, en Python on pouvait simplement ouvrir un process comme on ouvre un fichier avec os.popen.

    Oui, et on peut encore au moins dans python2.6. Citons la PEP incriminée : http://www.python.org/dev/peps/pep-0324/
    The functions and modules that this new module is trying to
    replace (os.system, os.spawn*, os.popen*, popen2.*, commands.*)
    are expected to be available in future Python versions for a long
    time, to preserve backwards compatibility.

    L'intérêt du remplacement c'est d'éviter d'avoir 12 façon différentes d'exécuter une commande dans os + celles de popen2 + celles de command en ajoutant des exceptions, en simplifiant la syntaxe dans certains cas (plus de shell escape).
    • [^] # Re: Avant après

      Posté par  . Évalué à -4.

      Je trouve que dans ce cas, la simplification c'est raté .... Je sais qu'on peut encore le faire, mais vu que c'est voué à disparaitre, je préfère m'abstenir.

      Enfin c'est du python, et j'ai un peu de mal à me faire à cette logique.
      • [^] # Re: Avant après

        Posté par  . Évalué à 2.

        popen, popen2, popen3 et popen4 ...

        Se débarrasser de ces noms moisis, j'ai du mal à le voir comme une régression, mais bon, question d'appréciation.
    • [^] # Re: Avant après

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

      Surtout que le support de différents popen sous Windows a longtemps été moisi, mais uniquement dans certains cas.

      au moins, avec subprocess, tu as une interface stable, qui couvre tous les besoins d'utilisation.
  • # Enfer et damnation !

    Posté par  (Mastodon) . Évalué à 10.

    Python évolue, bigre...
    Mais quelle horreur, vite pendons-le haut et court !


    Yth......
    • [^] # Re: Enfer et damnation !

      Posté par  . Évalué à -1.

      Qu'il évolue, pourquoi pas. Mais tant qu'à faire, il faudrait qu'il évolue en mieux.
      • [^] # Re: Enfer et damnation !

        Posté par  . Évalué à 10.

        Une fonction au lieux de 3, c'est pas mieux, déjà ?
        • [^] # Re: Enfer et damnation !

          Posté par  . Évalué à -6.

          Je ne connais pas python, je suis débutant en dev, mais je sais que réunir trois fonction en une, c'est pas toujours le top : t'imagine une fonction en c qui ferait tout ce qui concerne les systèmes de fichier (ouvrir fichier et dossier, déplacer le curseur.....)? Vois le bordel pour lire le code.

          J'ignore si dans ce cas, cette réunion est problématique, mais il me semble que l'avis de totof (même si avouons le, il est un peu extrémiste sur les bords... du moins sur ce sujet!), n'est pas à rejeter complètement.

          Et ce n'est pas parce qu'une communauté décide quelque chose que c'est forcément super méga tiptop de la bal pour le projet, sinon les fork n'existerait pas!

          Sur ce, Totof, si Python ça te plais pas, utilise un autre Langage.
          • [^] # Re: Enfer et damnation !

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

            C'est une seule fonctionnalité: lancer un process séparé.

            Après, la façon dont tu identifies le binaire, comment tu communiques avec ce process, comment tu fournis les paramètres, etc... ce ne sont que des options.

            Après, tu as le communicate() pour les besoins simples (mais les plus courants), et tu peux utiliser des pipes vers stdin/stdout/stderr pour les choses plus compliquées.

            Enfin, les os.spawn/exec, les popen & Co sont disponibles dans les versions 2.x de Python, ça ne change qu'à la version 3 qui est une évolution majeure du langage avec une réorganisation des librairies (et tu peux avoir la V2 et la V3 en parallèle).

            Bref, pour moi c'est un journal en effet inutile à la base (comme indiqué dans le titre)... mais qui donnera peut-être des indications à certains.

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

            • [^] # Re: Enfer et damnation !

              Posté par  . Évalué à -1.


              C'est une seule fonctionnalité: lancer un process séparé.
              Après, la façon dont tu identifies le binaire, comment tu communiques avec ce process, comment tu fournis les paramètres, etc... ce ne sont que des options.


              Mouais, réunir plusieurs fonctions (popen popen2, etc ..) en une seule (même fonctionnalité), pourquoi pas. Par contre je trouve que la façon de faire de Python n'est pas ddes plus intuitives. J'ai repris le code d'exemple que j'ai trouvé dans la doc tel quel, sans trop comprendre ce qu'il fait. Et pour un langage ou tout est explicite, je pense qu'il vaut mieux avoir 5 fonctions différentes pour 5 variantes d'une action plutot que d'avoir une seule fonction ou il faut spécifier explicitement des paramètres inutiles dans la plupart des cas. Je trouvais que l'ancienne version popen popen2, etc .. était plus claire dans son fonctionnement.

              Après, tu as le communicate() pour les besoins simples (mais les plus courants), et tu peux utiliser des pipes vers stdin/stdout/stderr pour les choses plus compliquées.

              Ce qui me gave c'est qu'un truc simple comme
              pipe = os.popen("cmd", 'r', bufsize)
              qui est très clair à comprendre devient
              pipe = Popen("cmd", shell=True, bufsize=bufsize,stdout=PIPE).stdout
              qui est quand même moins intuitif.
              • [^] # Re: Enfer et damnation !

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

                Moins intuitif pour toi et pour moi, parce que l'on connais déjà os.popen. Prend un débutant qui se farcit les docs... choisir le bon popen/spawn.../exec... et bien l'utiliser n'est pas évident, et en plus ces fonctions ont l'ordre des valeurs de retour qui peut différer... Là, avec la doc, ils t'indiquent comment faire pour mimer l'ancien usage ainsi que (AMA plus intéressant pour les nouveaux venus) les utilisations en Pipe shell.

                Et c'est plus sécure: là, tu indiques explicitement que tu vas aller utiliser le shell pour lancer la commande, donc qu'il peut y avoir une tromperie à ce niveau - tu dois en être conscient.

                Ceci dit, tant que tu restes en Python 2.x, tu peux continuer avec os.popen (mon treetaggerwrapper.py l'utilise encore, et il tourne très bien avec Python 2.6).

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

                • [^] # Re: Enfer et damnation !

                  Posté par  . Évalué à 3.

                  Moins intuitif pour toi et pour moi, parce que l'on connais déjà os.popen.
                  Enfin, quand tu compares les deux approches il n'y a pas photo. Dans le cas ou l'on veut récupérer le flux retourné par une commande la premiere solution reste la plus simple. Les histoires de pipe peuvent être intéressantes, mais pour le cas du popen simple, je trouve que ça embrouille plus qu'autre chose.

                  (AMA plus intéressant pour les nouveaux venus) les utilisations en Pipe shell.
                  C'est quand même sortir la grosse artillerie pour pas grand chose je trouve.

                  Et c'est plus sécure: là, tu indiques explicitement que tu vas aller utiliser le shell pour lancer la commande, donc qu'il peut y avoir une tromperie à ce niveau - tu dois en être conscient.
                  Mouais, ça reste dans l'état d'esprit Python, et c'est ce genre de truc que je n'aime pas. A force de devoir tout spécifier de façon implicite, on en arrive à l'incantation. Si j'ai besoin de programmer une appli nécessitant une fiabilité telle qu'il soit nécessaire de tout spécifier, je code en ADA, c'est fait pour.
              • [^] # Re: Enfer et damnation !

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

                Ce qui me gave c'est qu'un truc simple comme
                pipe = os.popen("cmd", 'r', bufsize)
                qui est très clair à comprendre devient
                pipe = Popen("cmd", shell=True, bufsize=bufsize, stdout=PIPE).stdout


                A priori, si tu préfères l'implicite, tu dois pouvoir faire
                Popen("cmd", "args", bufsize, None, None, PIPE, None, False, True).stdout qui est carrément mois intuitif.
      • [^] # Re: Enfer et damnation !

        Posté par  . Évalué à 6.

        Et forcément, ton avis est sûrement beaucoup plus pertinent que celui de ceux qui décident des orientations de ce language...
    • [^] # Re: Enfer et damnation !

      Posté par  (Mastodon) . Évalué à 4.

      pendons-le

      Par les pieds !
    • [^] # Re: Enfer et damnation !

      Posté par  . Évalué à 3.

      Même si l'exemple spécifique exposé dans ce journal n'est pas vraiment pertinent, la façon dont python évolue est un problème.

      Par exemple, un programme qui fonctionne avec la 2.5 va planter avec la 2.6, et trouver la ligne fautive va prendre plusieurs heures.

      Si je compare avec Perl --- ok, je déconne --- avec du C je disais donc, il ne m'est jamais arrivé de voir un programme buguer à l'exécution à cause d'une compilation avec gcc 3.4 plutôt que 3.3 par exemple. Pourtant mon expérience avec Python est insignifiante par rapport au C.

      Peut être que Python est un super langage, mais l'incompatibilité potentielle entre deux versions mineures est un des plus grands reproches que je peux lui faire. Un autre reproche est l'incompatibilité linux/windows/cygwin, mais bon, là ce n'est pas entièrement de sa faute.
      • [^] # Re: Enfer et damnation !

        Posté par  (Mastodon) . Évalué à 3.

        Je n'ai jamais directement été confronté à des problèmes de compatibilité entre deux versions mineures de GCC. Et par directement il faut comprendre dans un de mes programmes.
        Mais ça arrive, je l'ai subi plusieurs fois, avec des logiciels tiers qui ne compilent plus sous une nouvelle version de GCC.
        C'est plus courant qu'on ne le pense, parce que les paquets des distribs gèrent ces problèmes pour nous, mais ça arrive !

        Une version d'un logiciel va très bien compilé avec un GCC, et plus du tout avec la version suivante de GCC. souvent pour pas grand chose non plus, une poignée de lignes ou de fonctions, et hop c'est reparti, pour nous, utilisateurs, il suffit d'attendre la version suivante qui ne manque pas d'arriver, et hop, c'est réglé.

        Mais ce problème n'est pas spécifique au C.
        Et... Je n'ai de la même manière jamais directement été confronté aux problèmes soulevés par les changements de version mineure de python !
        Et pourtant je développe en python depuis sept ans maintenant, à de multiples niveaux : scripts, applications, web...
        Par contre c'est sûr que le passage à python 3 impose des changements, mais c'est très visible, il y a des outils aidant à la transition, bref c'est une grosse étape, mais s'il y en a une prochaine du même acabit, elle sera peut-être dans dix ans, et dans quinze ans on aura encore le support des anciens modes de fonctionnement pour ne pas casser la compatibilité, en ajoutant un "import obsolete_stuff" à ses fichiers !


        Yth.
        • [^] # Re: Enfer et damnation !

          Posté par  . Évalué à 2.

          Les problèmes de compilations avec gcc sont relativement courants, en général parce que l'appréciation entre warning et error change d'une version à l'autre, mais à chaque fois le problème apparait à la compilation et la correction prend 15s, à la rigueur 2mn si il faut chercher sur le net. Jamais je ne suis tombé sur un cas ou le problème apparaissait à l'exécution.

          Alors qu'en python, je me rappelle d'une erreur dans SCons où une ligne du style :
          « array += ['string'] » était interprété différemment selon que la 2.5 ou 2.6 était utilisée. Le problème apparaissant bien entendu longtemps après, à l'autre bout de l'arborescence, et m'a pris un bon moment à comprendre. Aprés l'avoir reporté, l'avis du mainteneur du projet était que faire marcher du code prévu pour la 2.5 avec la 2.6 n'était même pas envisageable et ça ne valait pas le coup de corriger le problème sur la branche du projet, c'est dire à quel point ce problème avec Python est flagrant.
          • [^] # Re: Enfer et damnation !

            Posté par  . Évalué à 1.

            Mouais ... Je connais pas mal python et je n'ai aucun exemple de problème de compatibilité ascendante.
            Si tu as un exemple de code qui tourne en 2.5 mais pas en 2.6 je suis preneur.

            Bien sur je ne parle pas des extensions.
            • [^] # Re: Enfer et damnation !

              Posté par  . Évalué à 2.

              • [^] # Re: Enfer et damnation !

                Posté par  . Évalué à 4.

                "as" est un mot-clé dans python depuis quelques temps déjà (au moins 2.4), c'est complètement con de l'utiliser comme nom de variable. À mon avis y'avait des warnings avant. OK, c'est pas tip top de passer de "warning" à "syntax error", mais voilà quoi, normalement on n'utilise pas des mots-clés comme nom de variable.
                • [^] # Re: Enfer et damnation !

                  Posté par  . Évalué à 1.

                  Effectivement bien joué je n'y avait pas pensé à celui là. Menfin ce genre de bug ça se corrige vite.

                  $ python2.5 -c 'as = 42'
                  <string>:1: Warning: 'as' will become a reserved keyword in Python 2.6
                  $ python2.4 -c 'as = 42'
                  $
            • [^] # Re: Enfer et damnation !

              Posté par  . Évalué à 2.

              http://scons.tigris.org/issues/show_bug.cgi?id=2424
              Il n'y a pas le code fautif, mais il y a de quoi le retrouver dans SCons à condition de mettre les mains dans le cambouis.

              Et si vraiment tu t'embêtes, un petit google de « python 2.6 not compatible » devrait t'occuper un moment :^)
      • [^] # Re: Enfer et damnation !

        Posté par  . Évalué à 2.

        Par exemple, un programme qui fonctionne avec la 2.5 va planter avec la 2.6, et trouver la ligne fautive va prendre plusieurs heures.

        Heu, c'est quand même assez rare, à moins que tu fasses des choses très crades.

        Peut être que Python est un super langage, mais l'incompatibilité potentielle entre deux versions mineures

        Il n'y a normalement pas d'incompatibilité entre deux versions mineures (sauf rares exceptions, encore une fois). Si tu en trouves une, http://bugs.python.org
  • # Et sinon ?

    Posté par  . Évalué à 9.

    Tu préfère gets à fgets ?
  • # Tu te réveilles ?

    Posté par  . Évalué à 10.

    Le module subprocess est apparu avec Python 2.4, ça fait bientôt six ans. La famille de fonctions os.popen* (mais également l'infâme os.system) est certes dépréciée mais elles ne sont supprimées qu'à partir de Python3.

    Qu'est-ce qui t'agace ? D'avoir une interface unifiée pour lancer un processus ? Une interface tout aussi simple qu'avant mais plus robuste ?
    • [^] # Re: Tu te réveilles ?

      Posté par  . Évalué à 10.

      Non ce qui l'agace c'est de voir qu'il avait tout faux en croyant que l'ancienne interface était bien.
  • # tu n'as qu' ...

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

    a coder la lib qui simule os.popen() à l'aide de subprocess ...

    si ce n'est pas déjà fait (et suis persuadé que ça doit déjà exister)

    sinon, subprocess : c'est vraiment bien ;-)
  • # Pourquoi les gens critiquent toujours python avec de mauvais argument

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

    Il y en a un de très bon d'argument pourquoi subprocess est bizarre. En lisant la doc on peut lire:

    Note The data read is buffered in memory, so do not use this method if the data size is large or unlimited.

    (pour communicate)

    et

    Warning Use communicate() rather than .stdin.write, .stdout.read or .stderr.read to avoid deadlocks due to any of the other OS pipe buffers filling up and blocking the child process.

    pour stdout/stdin/stderr

    Comme il n'y a pas d'autre moyen de communiquer avec le sous processus, je fais quoi si je ne veut pas deadlocker et si j'ai BEAUCOUP de donnée ?
    • [^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen

      Posté par  . Évalué à 0.

      tu fais pas, pas plus qu'en shell tu ne fais un less sur un fichier ou buffer plus grand que ta ram+swap
      • [^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen

        Posté par  . Évalué à 1.

        Heu… comment dire… tous les outils shell qui n’ont pas besoin de parcourir le fichier complet avalent sans problèmes des fichiers énormes ; ils se contentent de ne lire que le début du fichier. Il faut peut-être vérifier mais je suis quasi-certain que less ne déroge pas à la règle. De plus c’est typiquement une utilisation avec des tubes dont on parle (récupérer la sortie d’un autre programme), et c’est cela qui manque à Python nativement si j’ai bien compris.

        Et encore heureux qu’on puisse lire n’importe quel fichier quelque soit ça taille et quelque soit le langage utilisé !
    • [^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen

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

      Pour continuer dans les problèmes de Python, pas de récursion utilisable :
      % python
      >>> def fac(n):
      ...     def fac_aux(n, p):
      ...             if n == 1:
      ...                     return p
      ...             return fac_aux(n - 1, n*p)
      ...     return fac_aux(n, 1)
      ...
      >>> fac(5)
      120
      >>> fac(999)
      [ ... ]
        File "<stdin>", line 5, in fac_aux
        File "<stdin>", line 5, in fac_aux
      RuntimeError: maximum recursion depth exceeded
      % perl
      sub fac {
              sub fac_aux {
                      my ($n, $p) = @_;
                      return $p if $n == 1;
                      return fac_aux($n - 1, $n * $p);
              }
              my $n = shift;
              fac_aux($n, 1);
      }
      printf "\n%d - %d\n", fac(5), fac(1000000);
      ^D
      120 - -1
      (Bon, le résultat est numériquement faux, mais l'exemple porte sur la récursion; sinon j'aurais utilisé une bibliothèque bignum.) On ne parlera pas de l'impossibilité de dire qu'on veut déclarer à l'avance ses variables pour au moins éviter les typos (il paraît que c'est un avantage).
      • [^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen

        Posté par  . Évalué à 5.

        J'imagine que ce n'est pas ce que tu veux, mais au cas où ça intéresse quelqu'un : il est possible de changer la valeur maximale avec sys.setrecursionlimit()
      • [^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen

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

        Help on built-in function setrecursionlimit in module sys:

        setrecursionlimit(...)
        setrecursionlimit(n)

        Set the maximum depth of the Python interpreter stack to n. This
        limit prevents infinite recursion from causing an overflow of the C
        stack and crashing Python. The highest possible limit is platform-
        dependent.


        In [1]: import sys


        In [2]: sys.getrecursionlimit()
        Out[2]: 1000

        In [3]: sys.setrecursionlimit(10000)

        In [4]: def fac(n):
        ...: def fac_aux(n, p):
        ...: if n == 1:
        ...: return p
        ...: return fac_aux(n - 1, n*p)
        ...: return fac_aux(n, 1)
        ...:

        In [5]: fac(5)
        Out[5]: 120

        In [6]: fac(999)
        Out[6]: 402387260077093773543702433923003985719374864210714632543799910429938512398629020592044208486969404800479988610197196058631666872994808558901323829669944590997424504087073759918823627727188732519779505950995276120874975462497043601418278094646496291056393887437886487337119181045825783647849977012476632889835955735432513185323958463075557409114262417474349347553428646576611667797396668820291207379143853719588249808126867838374559731746136085379534524221586593201928090878297308431392844403281231558611036976801357304216168747609675871348312025478589320767169132448426236131412508780208000261683151027341827977704784635868170164365024153691398281264810213092761244896359928705114964975419909342221566832572080821333186116811553615836546984046708975602900950537616475847728421889679646244945160765353408198901385442487984959953319101723355556602139450399736280750137837615307127761926849034352625200015888535147331611702103968175921510907788019393178114194545257223865541461062892187960223838971476088506276862967146674697562911234082439208160153780889893964518263243671616762179168909779911903754031274622289988005195444414282012187361745992642956581746628302955570299024324153181617210465832036786906117260158783520751516284225540265170483304226143974286933061690897968482590125458327168226458066526769958652682272807075781391858178889652208164348344825993266043367660176999612831860788386150279465955131156552036093988180612138558600301435694527224206344631797460594682573103790084024432438465657245014402821885252470935190620929023136493273497565513958720559654228749774011413346962715422845862377387538230483865688976461927383814900140767310446640259899490222221765904339901886018566526485061799702356193897017860040811889729918311021171229845901641921068884387121855646124960798722908519296819372388642614839657382291123125024186649353143970137428531926649875337218940694281434118520158014123344828015051399694290153483077644569099073152433278288269864602789864321139083506217095002597389863554277196742822248757586765752344220207573630569498825087968928162753848863396909959826280956121450994871701244516461260379029309120889086942028510640182154399457156805941872748998094254742173582401063677404595741785160829230135358081840096996372524230560855903700624271243416909004153690105933983835777939410970027753472000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L


        [PS. je suis preneur de ta solution pour mettre du Python dans les commentaires linuxfr]

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

      • [^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen

        Posté par  . Évalué à 1.


        >>> import sys
        >>> sys.setrecursionlimit(10000)
        >>> fac(999)
        402387260077093773543702433923003985719(...)


        Sinon oui, le duck typing, on aime ou pas.
        Chaque langage a sa philosophie, pour tout ce qui est « défaut » inhérent à celle-ci, on programme en fonction ou on change de langage.
      • [^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen

        Posté par  . Évalué à 2.

        On ne parlera pas de l'impossibilité de dire qu'on veut déclarer à l'avance ses variables pour au moins éviter les typos

        Pour pratiquer abondamment le python, je me suis rarement fait piéger par ça. Je ne tape le nom complet d'une variable qu'une seule fois, ensuite, je laisse faire l'auto complétion (qui a le bon goût de préserver mes erreurs typographiques)

        ça marche aussi avec les langages de scripts.
    • [^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen

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

      Ben tu es prévenu alors tu passes outre le warning, tu utilises directement les pipes, et c'est à toi de contrôler que les communications se passent bien, éventuellement à avoir un thread qui écrive sur le stdin du processus fils, et un autre qui lise sur son stdout pour récupérer les résultats (si tu n'as que de la lecture, un seul thread suffit).
      Note que tu es dépendant de la façon dont l'autre process - ainsi que le système - gère les buffers d'entrée/sortie/pipe.

      Mais ce genre de problème n'est pas lié à l'existence de subprocess. J'ai un code de 2005 (treetaggerwrapper.py) qui utilise os.popen2, et qui a besoin d'un thread séparé pour pouvoir alimenter un process externe et en même temps récupérer ce qu'il génère.

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

      • [^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen

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

        De mon coté c'est plus la doc que j'accuse. Entre un message qui me dis que faut pas si c'est trop gros et un autre qui me dis que ca vas planter dans certains cas... Je suis un peu perdu.
        • [^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen

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

          Là, je te suis, on aurais qq chose comme sur la doc PHP, où il peut y avoir des contributions à la suite du contenu, ça permettrais à des utilisateurs de rapporter des expériences, donner plus d'exemples.

          La doc s'est (nettement) améliorée - elle est mieux structurée qu'avant - mais il y manque encore ce côté participatif/retour d'expérience.

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

          • [^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen

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

            C'est une chose que j'aimais et detestait de la doc PHP. Il fallait vraiment faire le tri dans les commentaires et generalement quand l'on ne savait pas trop quoi faire, les mauvais commentaires orientaient dans une mauvaise direction.
            • [^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen

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

              mais faut l'avouer, c'était bien pratique ...
              Dans la grosse majorité des cas, tu trouvais du "code de ce que tu voulais exactement faire avec cet api", et tu copiais/collais.
              Certes, il y avait aussi des exemples qu'il ne fallait absolument pas reproduire ;-)
              Mais avec un petit système de modération +/- sur les com pertinents ... on aurait certainement le meilleur des 2 mondes.

              N'empêche qu'il me semble qu'ils avaient parler justement de faire un système d'annotation en live (tout ajax), lors du passage de l'ancien système à sphinx .. mais apparemment ça n'a pas été retenu ...
            • [^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen

              Posté par  . Évalué à 3.

              Et comment reconnaitre un mauvais commentaire d'un bon commentaire ?
              • [^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen

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


                Et bien ceux avec la meilleur note seront pertinants... Cela marche bien sur slashdot et linuxfr, alors pourquoi pas sur la doc python.
                • [^] # Circular Reference Warning

                  Posté par  . Évalué à 2.

                  One or more formulas contain a circular reference and may not calculate correctly. Circular references are any references within a formula that depend upon the results of that same formula. For example, a cell that refers to its own value or a cell that refers to another cell which depends on the original cell's value both contain circular references. For more information about understanding, finding, and removing circular references, click ok.
  • # Encapsulation

    Posté par  . Évalué à 2.

    L'un des plus gros avantage que je trouve dans le paradigme objet c'est encapsulation, de plus depuis que je sais ce qu'est un invariant de classe je considère l'encapsulation comme primordiale.

    Si je ne me trompe pas ce n'est pas réellement possible d'avoir des donnée membres private/protected. C'est le vrai tur qui me gêne avec le python mais sinon j'aime bien. :)

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Encapsulation

      Posté par  . Évalué à 2.

      ce n'est pas réellement possible d'avoir des donnée membres private/protected

      Effectivement. Mais ces qualificatifs n'ont toujours été que des indications pour le programmeur : il y a toujours moyen de le contourner dans le langage. D'où le principe de python d'en faire une indication "visuelle" seulement : quand tu veux faire du "private", tu préfixes ta variable avec deux underscore. Pour du "protected", avec un underscore.
      • [^] # Re: Encapsulation

        Posté par  . Évalué à 3.

        « il y a toujours moyen de le contourner dans le langage »

        En C++ j'imagine bien, en D, en Java, en C#, par exemple j'ai déjà plus de mal à imaginer le truc.

        De plus il me semble qu'une erreur renvoyée par le compilateur est un peu plus qu'une convention de nommage (pour les cas triviaux je parle pas d'aller faire mumuse avec l'arithmétique des pointeurs ni d'aller bidouiller le code générer par le compilateur).

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Encapsulation

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

          Grace à java.lang.reflect.


          public class ProofOfConcept {

          static class Foo {
          private String bar = "private";

          @Override
          public String toString() {
          return "bar = " + bar;
          }
          }

          public static void main(String[] args) {
          Foo foo = new Foo();
          try {
          System.out.println(foo);
          Field field = foo.getClass().getDeclaredField("bar");
          field.setAccessible(true);
          field.set(foo, "public");
          System.out.println(foo);
          } catch (Exception e) {
          e.printStackTrace();
          }
          }
          }


          Le résultat donne bien

          bar = private
          bar = public

          Alexandre COLLIGNON

    • [^] # Re: Encapsulation

      Posté par  . Évalué à 1.

      Si je reprend l'exemple de wikipedia http://en.wikipedia.org/wiki/Class_invariant#Examples
      en python ça donne:
      class Date(object):

          def __init__(self, day):
              self.day = day

          @property
           def day(self):
               return self._day

           @day.setter
           def day(self, day):
               assert 1 <= day <= 31
               self._day = day


      d = Date(2)
      d = Date(42)


      Avec un code comme ça pas d'erreur possible. Si quelqu'un modifie _day depuis l'extérieur de la classe et que son code pête il n'a que ce qu'il mérite.

      NB j'utilise la syntaxe 2.6 mais il en existe une compatible de 2.2 à 2.6
      • [^] # Re: Encapsulation

        Posté par  . Évalué à 2.

        En fait tu « cache » la donnée membre par une fonction du même nom si je ne me trompe pas, c'est ça ?

        Si oui il va falloir le faire pour toutes tes données membres ce qui n'es pas très pratique.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Encapsulation

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

          En Python le "pratique" c'est 'x' public, '_x' attention dépendant de l'implementation, '__x' privé à la classe.
          Le côté "on laisse accessible" est dans l'esprit de Python, aucun pythoneur n'ira faire ça pour toutes ses données membres - ou alors c'est un adepte de ADA/Java/C++ qui essaie d'apporter l'esprit de ces langages dans Python - il faut qu'il change d'esprit ou de langage.

          Les property, qui permettent de créer des accesseurs pour limiter/contrôler ce qu'on fait avec les variables membres, sont utilisées soit lorsque tu as vraiment besoin de faire des contrôles, soit quand on a du refactoring - pour ne pas casser les utilisations qui feraient des appels directs à une variable.

          C'est sûr que Python n'est pas fait pour les personnes qui veulent un typage statique et des contrôles d'accès sur les attributs et méthodes. Chaque langage a ses usages, ses limites... et ses adeptes. Python n'est pas fait pour les "ingénieurs logiciels". Mais ils ont largement le choix d'autres langages.

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

          • [^] # Re: Encapsulation

            Posté par  . Évalué à 1.

            Python n'est pas fait pour les "ingénieurs logiciels"

            Qu'appelles-tu "ingénieur logiciel" ?
            • [^] # Re: Encapsulation

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

              Je l'ai exprès mis entre guillemet. C'est à prendre dans le sens des gens qui veulent faire des développements très contrôlés de partout (les contrôles de types à la compil, les contrôles d'accès aux données...éventuellement de la preuve de code). AMA pour ça il y a ADA et dans une moindre mesure Java.

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

        • [^] # Re: Encapsulation

          Posté par  . Évalué à 3.

          > En fait tu « cache » la donnée membre par une fonction du même nom si je ne me trompe pas, c'est ça ?

          Non je crée une "property", ça permet de définir une fonction qui interceptera les assignations.

          > Si oui il va falloir le faire pour toutes tes données membres ce qui n'es pas très pratique.

          Oui et non. Personnellement je ne le fait que quand ça a un réel intérêt car j'adhère à la maxime pythonique We're all consenting adults here.
          Mais pour un Javaïste c'est équivalent à écrire un couple getter/setter donc bon...

          Et puis grâce au coté dynamique de python tu peut écrire des sortes properties générique aka descriptors et tu n'aura plus qu'a déclarer.
          Les modèles Django sont basés la dessus.

          http://docs.djangoproject.com/en/1.2/topics/db/models/#field(...)
  • # [HUMOUR] on n'est pas vendredi

    Posté par  . Évalué à -1.

    mais la principale raison pour laquel python est pourri est la syntaxe.

    Désolé, cette indentation la con me donne des boutons. Python j'ai essayé, j'en ai fait, j'aime le fait que ce soit flexible, mais syntaxiquement, je peux pas. Je vomis après avoir coder, et j'ai la diarrée quand je lit un fichier python.

    Donc, une petite pensée pour tous ceux qui comme moi ont développé une alergie au python.

    PS: pour vous dire, je préfère encore coder un script en PERL ou en PHP cli plutot que de taper une ligne de code python....
    • [^] # Re: [HUMOUR] on n'est pas vendredi

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

      TOUTAFE, d'ailleurs, je préfère de loin utiliser whitespace, il n'y a rien qui dérange les yeux: le grand blanc [*], l'immensité désertique des pixels.


      [*] Ou autre, ça dépend du fond de la fenêtre d'édition.

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

    • [^] # Re: [HUMOUR] on n'est pas vendredi

      Posté par  . Évalué à 4.

      > Désolé, cette indentation la con me donne des boutons
      > PS: pour vous dire, je préfère encore coder un script en PERL ou en PHP cli plutot que de taper une ligne de code python....

      Toi, t'es le genre à aimer le code pas lisible et imbitable.
      • [^] # Re: [HUMOUR] on n'est pas vendredi

        Posté par  . Évalué à 2.

        En perl ou en php, je PEUX faire du code "beau". On peut faire pire.

        En python, je n'y arrive pas. C'est moche dès le premier caractère.
        • [^] # Re: [HUMOUR] on n'est pas vendredi

          Posté par  . Évalué à 2.

          Je te crois sur parole, perl et php sont certainement plus appropriés que Python pour faire de l'ascii art. :o)

          L'important c'est que le code soit lisible, concis et fonctionnel, le choix de l'indentation pour définir les blocs dans Python aide grandement pour les deux premiers points.
          • [^] # Re: [HUMOUR] on n'est pas vendredi

            Posté par  . Évalué à 1.

            heu je suis sérieux quand je dis que le code python est plus horrible que du code php/perl. Les indentation a la python rend un code un poil long absolument ILLISIBLE.
            • [^] # Re: [HUMOUR] on n'est pas vendredi

              Posté par  . Évalué à 4.

              Comme dit Linus If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

              En général, le code perl et PHP est nettement plus cryptique que son équivalent Python. AMHA, on peut trouver des contre-exemples mais ça demande beaucoup plus d'efforts.
              • [^] # Re: [HUMOUR] on n'est pas vendredi

                Posté par  . Évalué à -1.

                c'est pas une question de contre exemples. C'est une question de ressenti, purement subjectif. J'aime pas l'indentation à la con de python.
                J'aime pas le fait de ne pas avoir d'accolade pour délimiter mes blocs.
                J'aime pas le fait de ne pas voir où se termine ma fonction rapidement ou ma classe !
        • [^] # Re: [HUMOUR] on n'est pas vendredi

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

          Ah, la définition de la beauté. Les goûts et les couleurs...

          Mais quand même, PHP, Perl, Python... ça commence très souvent par un #! du shebang au début du fichier. Donc, si c'est moche dès le premier caractère... y'a un truc.

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

          • [^] # Re: [HUMOUR] on n'est pas vendredi

            Posté par  . Évalué à 4.

            C'est vrai que d'un point de vu ésthétique, il n'y a que piet qui permette de coder quelque chose d'agréable à regarder.
    • [^] # Re: [HUMOUR] on n'est pas vendredi

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

      Tu devrais essayer de coder en code barre.

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

Suivre le flux des commentaires

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