Proposition de moratoire de plusieurs années sur le coeur du langage Python

Posté par  (site web personnel) . Modéré par patrick_g.
Étiquettes : aucune
26
22
oct.
2009
Python
Guido Van Rossum a proposé hier un moratoire de plusieurs années sur le cœur du langage Python. Si cette proposition est retenue, alors aucun changement dans la grammaire et la sémantique du langage ne sera accepté durant cette période. La bibliothèque standard n'est donc pas concernée.

Guido Van Rossum donne comme raison pour ce moratoire les difficultés d'implémentation des versions alternatives de Python. CPython étant l'implémentation la plus répandue (standard de facto) et installée sur la plupart des distributions GNU/Linux actuelles, GvR parle de Jython, IronPython, PyPy et d'autres.

Le créateur du langage Python pense également que ce moratoire permettrait à Python 3.x de se diffuser plus largement qu'il ne l'est à l'heure actuelle.

Il est vrai que la transition de Python 2.x vers 3.x a été une source de perturbations importantes, 3.x cassant en effet la compatibilité avec la branche 2.x et 3.x est loin d'être aussi utilisée que la 2.x.
Debian ne travaille en ce moment qu'à la mise en place de Python 2.6 en tant que version par défaut de leurs systèmes. Cette proposition de Guido Van Rossum sera, si elle est acceptée, lourde de conséquences (bonnes ou mauvaises, l'avenir le dira) sur l'avenir du serpent le plus inventif qu'ait apprivoisé la communauté du libre depuis son commencement.

Aller plus loin

  • # Curieux les perturbations

    Posté par  . Évalué à 2.

    Je ne suis pas un expert en Python mais j'avais l'impression que les changement 2.6 -> 3.x n'étaient pas si important que cela..

    En tout cas par rapport a Ruby 1.9, c'était l'impression que j'en avais..
    • [^] # Re: Curieux les perturbations

      Posté par  . Évalué à 5.

      Entre 2.6 -> 3.x non parceque 2.6 est la pour faire la transition et si tu regardes du cote de 2.5 versus 3.x la cela se gate. Par exemple: la fonction print ou encore l'operateur %

      Ce ne sont pas vraiment des details surtout sachant que par exemple la plupart des mac ont encore 2.5 ce qui fait que si tu veux faire un truc portable ben tu dois te limiter cette version.
    • [^] # Re: Curieux les perturbations

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

      Le problème est que seul CPython implémente complètement « Python » (le langage et la bibliothèque standard), c'est le standard de facto. Par contre, PyPy et Jython en sont à Python 2.5 et IronPython se prépare à Python 2.6. PyPy, Jython et IronPython n'ont sont même pas encore à Python 2.6 (sorti il y a un peu plus d'un an), que CPython court déjà vers Python 3.2 et bientôt 2.7...

      En d'autres termes, passer de la version 2.x à 2.x+1 prend trop de temps qu'on ne peut même pas encore envisager la migration à Python 3.1 (manque de main d'œuvre).

      Au sujet de la migration des projets utilisant Python 2.x et voulant migrer à Python 3.x, il y a un outil de migration (2to3) qui permet de corriger la syntaxe. Par contre, le problème est plus au niveau des bibliothèques (PyQt, Twisted, Django, ...) qui migrent doucement vers Python3.

      PS : Unladen Swallow est un fork de la version 2.6.1, donc pareil, pas de Python3 pour cette implémentation pour le moment.
      • [^] # Re: Curieux les perturbations

        Posté par  . Évalué à -1.

        Dans ta liste il manque a mon avis les projet numpy, scipy et matplotlib (celui la en est encore a python2.4)...
        Donc ca va pas etre tout de suite la migration vers 3.x en effet.
        • [^] # Re: Curieux les perturbations

          Posté par  . Évalué à 3.

          matplotlib (celui la en est encore a python2.4)
          matplotlib builde très bien sur python 2.6.1 et numpy 1.3. Je vois pas où t'as vu la limitation!
          • [^] # Re: Curieux les perturbations

            Posté par  . Évalué à 1.

            Je n'ai jamais dit que l'on ne pouvait pas le faire fonctionner avec 2.6 j'ai dit (et c'est pas moi qui le dit mais la page de matplotlib) que cette librairie n'utilise pas les fonctionnalites de python > 2.4

            L'un n'exclut pas l'autre.

            http://matplotlib.sourceforge.net/devel/coding_guide.html

            Are your changes python2.4 compatible? We still support 2.4, so avoid features new to 2.5
            • [^] # Re: Curieux les perturbations

              Posté par  . Évalué à 2.

              de ton lien:
              When committing changes to matplotlib, there are a few things to bear in mind.
              - Are your changes python2.4 compatible? We still support 2.4, so avoid features new to 2.5


              C'est pas parce qu'ils demandent aux développeurs de coder du python compatible 2.4 que matplotlib ne tourne pas sur 2.6!

              Ta phrase était quelque peu ambigüe, et sous entendait que ça ne tournait que en 2.4.
              • [^] # Re: Curieux les perturbations

                Posté par  . Évalué à 3.

                Oui enfin il y a aucun programme python 2.4 qui soit incompatible avec 2.5 ou 2.6 (en dehors de bug) donc je vois pas trop ton raisonnement. Enfin si tu en connais n'hesite pas a nous en faire part...
              • [^] # Re: Curieux les perturbations

                Posté par  . Évalué à 2.

                De plus le point souleve par Victor etait le fait que des composants important de python n'etait toujours pas porte sur python3. Du coup je mentionnais des projets, important pour moi en tout cas, qui etait encore a NE PAS utilise python 2.5 et superieur.
                Ils vont probablement passer directement a python3 mais bon vu l'apport pour les chaines de carecteres par exemple cela aurait ete pas mal un passage a 2.6.
    • [^] # Re: Curieux les perturbations

      Posté par  . Évalué à 2.

      A finir par se demander si le problème de migration vient de Python 3 ou de la communication qui est faite autour.

      Après avoir vu des journaux expliquer que la 2.6 c'était pour préparer une migration en douceur, la sortie de la 3 a provoqué un déluge pour expliquer que ça allait tout casser les programmes actuels.

      Et j'ai vu passer tout ça alors que je ne suis pas programmeur. C'est dire si ça a dû être répété...
      • [^] # Re: Curieux les perturbations

        Posté par  . Évalué à 3.

        Je ne comprends pas trop où est la controverse. Oui, la version 3 casse la compatibilité, c'est volontaire et ça fait partie de ses raisons d'être.

        Ensuite, la version 2.6 rend la transition moins difficile, mais il n'est pas conseillé (sauf petits scripts) d'essayer d'écrire du code qui soit à la fois compatible 2.6 et 3.x. La méthode recommandée est d'utiliser l'outil "2to3".
    • [^] # Commentaire supprimé

      Posté par  . Évalué à 5.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # S'engager au freeze?

    Posté par  . Évalué à 2.

    s'engager au freeze, la garanti de non-evolution.... en informatique ça me fait assez peur, j'ai beau être adepte de python, je pense que la synthaxe reste perfectible...

    par exemple, je remplacerai bien les métaclasses par des décorateurs de classes pour montrer que c'est comparable à des décorateurs de fonctions...

    Enfin pour ma part, si je ne balance pas ver 3.x de python, c'est pour deux raisons claire, en un le fait qu'on y perde en performance et en deux c'est que si c'est pour un site web héberger sur du mutualisé... bha c'est encore pas vraiment possible... mais tant que python 3 a des performances moindres que celles de 2.6 et qu'il n'a pas de vrai valeurs ajoutées... pas envisageable... il a aucune libs compatibles encore...

    http://shootout.alioth.debian.org/u32q/benchmark.php?test=al(...)
    • [^] # Re: S'engager au freeze?

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

      s'engager au freeze, la garanti de non-evolution...

      Il ne s'agit que de figer le langage, la bibliothèque standard va continuer à évoluer, comme indiqué dans la dépêche.

      je pense que la synthaxe reste perfectible

      Les ajouts récents (with, décorateur de classe, etc.) sont du sucre syntaxique, càd qu'on peut s'en passer. Je pense que le noyau dur du langage (définition d'une fonction/classe, les modules, les boucles, les exceptions, etc.) est stable et cohérent, et qu'on devrait y survivre durant quelques années. S'il y avait des énormités insupportables, ils ont été corrigés ou alors ce n'était pas si insupportable que ça :-)

      si je ne balance pas ver 3.x de python (...) qu'on y perde en performance

      Unladen Swallow et PyPy ont un compilateur à la volée (JIT) qui montre de gros gains de performances, c'est très prometteur. Si Python2 devient 5x plus rapide mais que Python3 reste 30% plus lent que Python2, je pense que les 30% deviendront négligeables (ou dumoins, acceptables).

      Petit à petit, les nouvelles fonctions et optimisations arrivent plutôt dans Python3 que dans Python2.
    • [^] # Re: S'engager au freeze?

      Posté par  . Évalué à 4.

      j'ai beau être adepte de python, je pense que la synthaxe reste perfectible

      Ah, tu veux améliaurer la synthaxe ?...

      je remplacerai bien les métaclasses par des décorateurs de classes

      Les décorateurs de classes existent déjà.

      Ceci dit, des tas de gens ont des tas d'idées plus ou moins farfelues sur des façons de soi-disant "améliorer" Python, cela n'en fait pas des choses souhaitables. La liste "python-ideas" est chargée de propositions qui n'ont aucune chance d'aboutir, parce que mal pensées ou n'apportant aucune nouveauté réelle.

      mais tant que python 3 a des performances moindres que celles de 2.6 et qu'il n'a pas de vrai valeurs ajoutées

      Sur la performance, ça dépend des usages.
      Sur la valeur ajoutée, rien que les chaînes de caractères unicode par défaut et la distinction stricte avec les chaînes 8 bits vaut le coup. C'est beaucoup plus utile que les décorateurs de classes...
      • [^] # Re: S'engager au freeze?

        Posté par  . Évalué à 1.

        Je concède qu'utiliser django fait que tout est en UTF8 sans avoir à songer à quoi que ce soit d'autre... je suis conscient des réelles améliorations de python 3.. mais ce sont des améliorations certes pratiques mais pas indispensable...

        Les décorateurs de fonctions existent... j'avai lu un mail de refus de Mr python pour les décorateurs de classe (de 2004) mais effectivement en 2006 ça a été accepté...( http://mail.python.org/pipermail/python-dev/2006-March/06294(...) )

        Du coup, effectivement le décorateur de classe est une nouveauté de python 3k :paf:, j'avai pas repéré ça dans le what's new...

        Néanmois, je voix par exemple le C# qui est un langage qui bouge beaucoup... bon on a depuis longtemps la pluspart des fonctionnalités qu'ils ajoutent... (C#4 avec les paramètres nommés, le typage dynamique ^^...) ils ont des évolution de syntaxe comme leurs expressions lambdas, leur Linq qui sont potentiellement interessants...

        C#: x=>x+2
        Python: lambda x:x+2

        enfin, dans la mesure du possible je préfaire développer en python, mais si une idée géniale survien, elle est limitée aux versions patché jusqu'à la levée du moratoire...
        • [^] # Re: S'engager au freeze?

          Posté par  . Évalué à 3.

          L'exemple de C# est assez mauvais car le meme probleme existe vu que la seule autre version (mono) est a la bourre par rapport a la seul version officielle. Donc ca bouge et en dehors de l'implementation de reference l'autre rame derriere comme pour python.
          • [^] # Re: S'engager au freeze?

            Posté par  . Évalué à 0.

            je ne trouve pas que mono rame derrière .NET, ils font d'autres choses... en l'occurence cette syntaxe est gérée et ce n'est pas le problème dans ce cas... c'est un exemple de synthaxe que je trouve un peu plus simpas ailleur qu'en python...

            Comme le dit Miguel lui même, si on voit mono comme une lib de compatibilité ce sera toujours à la traine mais c'est bien plus que ça, ça a beaucoup d'autres fonctionnalités que n'a pas .NET mais c'est vrai que leurs libs complémentaires tentant d'être compatibles .NET, il n'a de plus que certaines fonctionnalités pour le multitasking, le SIMD, le Csharp shell, la possibilité de faire un framework réduit sur mesure, les libs Iphone, des libs Terminal linux, une intégration DBus... mais a apporté à .NET par sa simple existance et ses choix de portabilité GTK#, {postgreSQL?}, des libs d'extentions, de gestion d'options de commandes, un annalyseur syntaxique, un IDE, libs ogg, libs de tags mp3, libs gecko....

            Mais je suis d'accord mono est carrément à la traine derière .NET... ou pas tant que ça en fait... c'est juste des implémentations différentes...
            • [^] # Re: S'engager au freeze?

              Posté par  . Évalué à 1.

              ça intéresse qui Mono ? et l'avis de "Miguel lui-même" ?
              Franchement....
              • [^] # Re: S'engager au freeze?

                Posté par  . Évalué à 0.

                Je sais bien que ce n'est pas le sujet, je répondait juste à l'attaque D'Albert_.
                Pour ma part, je trouve que mono est un projet interessant si ça ne t'interesse pas, je m'excuse d'avoir posté ce commentaire au grand maitre... je suis convaicu que tous les membres de linuxfr se désinteresse entièrement de mono...

                Ou pas remarque c'est une technologie de développement opensource qui est très utilisée et qui fait beaucoup parler d'elle et qui attaqué injustement, et je trouvé cette réponse certes un peu capillo-tracté plus pertinante ici que dans un message privé.
                • [^] # Re: S'engager au freeze?

                  Posté par  . Évalué à 3.

                  je répondait juste à l'attaque D'Albert_.

                  Je suis ecroule de rire, franchement. Il doit y avoir une session lavage de cerveau sur Albert dans la secte Microsoft/C# c'est pas croyable.

                  L'exemple de C# est assez mauvais car le meme probleme existe vu que la seule autre version (mono) est a la bourre par rapport a la seul version officielle. Donc ca bouge et en dehors de l'implementation de reference l'autre rame derriere comme pour python.

                  Voir une attaque dans cette reponse cela me laisse perplexe.
                  • [^] # Re: S'engager au freeze?

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

                    C'est rigolo votre quiproquo : Crovax31 citait juste C# parcqu'il y avait des trucs dedans intéressant qui pouvaient être incorporé dans Python et que si la grammaire freeze c'est dommage.

                    Albert croit qu'il compare la politique d'évolution de C# et de Python alors qu'en fait non il prenait juste un exemple de syntaxe sympa et indique que mono est, comme pour Python, toujours à la traîne, ce qui est vrai.

                    Crovax31 voit une attaque et rappelle que Mono n'est pas à la traîne sur les libs. Ce qui n'est pas faux, mais ne contredit en rien ce que dit Albert : mono est en retard en ce qui concerne le langage C# lui-même, ce qui est tout à fait vrai.

                    Tout le monde a raison \o/
              • [^] # Re: S'engager au freeze?

                Posté par  . Évalué à 1.

                Qui plus est mono est quasiment au coeur du sujet vu qu'on parle de ralentissement pour encourager les implémentations tierces dont Jython et IronPython...
  • # différence entre dev et prod

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

    j'ai lu quelques discussions de la mailing-liste python-dev, des personnes sans doute brillantes s'exprimaient, mails il était évident que la majorité de ces personnes n'avaient aucune idée de ce qu'est une appli en production, qui doit fonctionner, pour laquelle 2 heures d'arrêt est une catastrophe, je ne parle pas d'une journée ou plus...

    ウィズコロナ

    • [^] # Re: différence entre dev et prod

      Posté par  . Évalué à 1.

      :second degré:
      Celui qui decide au final c'est un noob qui connait rien à la vie d'entreprise... il est embauché par une petite boite qui a rien à faire de la fiabilité des technologies... Google...
      :second degré:

      Après les mail-lists publiques, tout le monde peut s'inscrire pour publier leurs idées, il n'y a forcément pas que des lumières...

      Moi même il m'est arrivé de soumettre des suggestion sur un sujet que je maitrisait mal sur des mailing list de developpement...

      Mais au final, ce n'est pas nécessairement représentatif de la fiabilité du logiciel final...
      • [^] # Re: différence entre dev et prod

        Posté par  . Évalué à -1.

        (mes excuses pour le hors sujet mais dire que mono est à la traine... il implémente des fonctionalités de C#4 avant sa sortie... pour ce qui est du l'angage il est à l'avance mais ce qui est des libs... on peut pas demander des miracles...
  • # Et sur debian ...

    Posté par  . Évalué à 1.

    Sur ma sid, j'ai la version 2.5.4.

    J'ai vu que que la 2.6 et la 3 était disponible en expérimentale http://wiki.debian.org/Python3 .

    Est-ce quelqu'un a déjà fait cohabiter ces versions ?

    Je me disais que via update-alternatives cela devrait pouvoir se faire mais j'ai pas trouvé de trucs concluants.

    Pour moi, c'est cela qui me gène le plus pour tester ...

    Merci de vos retours.
    • [^] # Re: Et sur debian ...

      Posté par  . Évalué à 1.

      la cohabitation est viable, python pointe probablement vers python2.5/python2.6 après tu peux utiliser python3 manuellement si plusieurs sont installés...

      pour ma part j'ai 2.5, 2.6 et 3.1 d'installés...
    • [^] # Re: Et sur debian ...

      Posté par  . Évalué à 3.

      J'ai installé python2.6 et python3.1 depuis experimental sur ma squeeze testing. Comme mon idée était seulement de m'amuser avec les nouveautés de la syntaxe, je n'ai pas poussé l'investigation très loin, mais il m'a semblé que les différentes versions cohabitent sans problème.
      Pour l'installation je n'ai rien de fait de spécial, il suffit d'installer les paquets.
      J'ai également ajouté les lignes suivantes dans /etc/apt/preferences:

      Package: python3.1 python3.1-minimal python3.1-doc python3.1-examples libpython3.1
      Pin: release a=experimental
      Pin-Priority: 990

      Package: python2.6 python2.6-minimal python2.6-doc python2.6-examples libpython2.6
      Pin: release a=experimental
      Pin-Priority: 990


      J'ai vérifié dans squeeze, il n'y a effectivement pas de règles update-alternatives associée à python. Il n'est de toute façon pas prudent de choisir une autre version que 2.5 en tant que version par défaut.

      On se contente donc d'appeler explicitement la version voulue à partir des commandes python2.6 ou python3.1.
      Dans un script il suffit de placer en première ligne un shebang du type:
      #!/usr/bin/env python2.6
      ou
      #!/usr/bin/env python3.1
  • # Depuis le début

    Posté par  . Évalué à 8.

    Je suis l'évolution de Python depuis sa naissance, et je l'utilise, par intermitence il est vrai (je suis dev java dans la vie professionnelle.

    Bon, j'ai pas encore trouvé le langage idéal selon moi. Il y a des truc que je trouve moche dans Python, que j'aurai fait autrement, etc. Mais ce que je retiens, c'est que jusqu'à maintenant, chaque fois que j'ai ouvert un source Python, j'ai compris plutôt rapidement ce qu'il se passait à l'intérieur.
    Et pour moi, c'est un avantage prépondérant qui me fera préférer ce langage à beaucoup d'autre. C'est vrai qu'en Java, c'est a peu près pareil, mais j'en bouffe toute la journée, donc ça compte pas, mon cerveau doit être trop déformé.

    Cette lisibilité, on la doit au développeur d'abord, mais aussi au concepteur du langage, qui a toujours pesé le pour et le contre avec grand soin.
    De plus je pense que Guido est un homme intelligent, il sait prendre son temps, et sais aussi changer d'avis, si on lui montre qu'il a tord, ça s'est déjà vu.

    Bref, j'aime Python et j'ai entièrement confiance en Guido pour continuer à proposer un langage sans bloat, lisible, et qui continue d'évoluer. Peut-être moins sexy que son cousin Ruby, mais tellement efficace ;)
    • [^] # Re: Depuis le début

      Posté par  . Évalué à 4.

      >Peut-être moins sexy que son cousin Ruby, mais tellement efficace ;)

      Comme c'est Vendredi, je vais repondre a cela: 'tellement efficace'?
      Ruby et Python sont tous les deux tres lents.

      'Moins sexy'?
      A une epoque je voulais apprendre un nouveau langage de script (je n'aime pas le shell, je deteste le Perl) et j'avais regarde les 2: ma conclusion est que les deux etait vraiment tres, tres similaire en fait.
      Mais depuis quand je vois les nombreux changement 'subtils' de Ruby 1.8 -> 1.9 et en comparaison le faible nombre de changement Python 2.x -> 3.x, je me demande si le choix de la simplicite pour Python n'est pas le bon choix plutot que d'avoir une syntaxe 'sexy' qui peut facilement se transformer en 'trop compliqué'..
      • [^] # Re: Depuis le début

        Posté par  . Évalué à 1.

        Python peut être extrêmement rapide avec psyco. La difficulté est qu'il ne suffit pas d'importer psyco, il faut aussi adapter son code pour en profiter réellement. Un code optimisé pour python seul ne le sera pas forcément pour python+psyco et inversement. C'est un peu comme en Java, si on fait gaffe on peut obtenir un code proche de la vitesse du C mais si on ne fait pas gaffe ça peut être catastrophique. Je ne sais pas ce qu'il en est avec ruby...

        Le fait de geler le langage pendant quelque temps va permettre aux projets comme unladen swallow, pypy etc de devenir réellement viables et d'enterrer définitivement cette impression de lenteur qu'on peu parfois percevoir.
        • [^] # Re: Depuis le début

          Posté par  . Évalué à 1.

          J'oubliais, en passant, unladen swallow Q3 est sorti y a 3j...
          http://code.google.com/p/unladen-swallow/wiki/Release2009Q3

          * Unladen Swallow 2009Q3 uses up to 930% less memory than the 2009Q2 release.
          * Execution performance has improved by 15-70%, depending on benchmark.
          * Unladen Swallow 2009Q3 integrates with gdb 7.0 to better support debugging of JIT-compiled code.
          * Unladen Swallow 2009Q3 integrates with OProfile 0.9.4 and later to provide seemless profiling across Python and C code, if configured with --with-oprofile=<oprofile-prefix>.
          * Many bugs and restrictions in LLVM's JIT have been fixed. In particular, the 2009Q2 limitation of 16MB of machine code has been lifted.
          * Unladen Swallow 2009Q3 passes the tests for all the third-party tools and libraries listed on the Testing page. Significantly for many projects, this includes compatibility with Twisted, Django, NumPy and Swig.

          Et sur le blog de pypy les résultats annoncés sont pour le moins impressionnants...
          http://morepypy.blogspot.com/
          • [^] # Re: Depuis le début

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

            >>> * Unladen Swallow 2009Q3 uses up to 930% less memory than the 2009Q2 release.

            Heu comment c'est possible ça ?
            • [^] # Re: Depuis le début

              Posté par  . Évalué à 2.

              Moi aussi cela m'a surpris, mais en visitant le lien déjà mentionné, on constate que leur base de calcul est la suivante :

              % = (M3-M2)/M2*100

              M3 = mémoire utilisée dans la version 3
              M2 = mémoire utilisée dans la version 2

              Tout s'éclaire !
        • [^] # Re: Depuis le début

          Posté par  . Évalué à 5.

          Tout a fait ;)
          Quand je parlais d'efficacité, je parlais surtout en temps de développement, facilité de prise en main d'un code existant, etc.

          Maintenant niveau perf, c'est largement suffisant pour ce que j'ai à faire. Dans certains cas, la vitesse peut être un critère, je ne le nie pas, mais j'ai l'impression que bien souvent, c'est plutôt un tic de geek, maniaque de la vitesse à tout prix.

          Pour moi, si mon programme Python s'exécute en 0.4s, et qu'il m'a fallu 2 heures pour le développer, je suis largement plus satisfait que s'il s'execute en 0.05s, après 3 jour de dev en C.

          Après, si des gens optimise encore l'interpréteur, ou fournisse un compilateur JIT, c'est tout bonus, je prend aussi ;)

          Parfois j'aimerai bien faire mes petits dev en Haskell ou ocaml, mais bien souvent là aussi, le coté "Battery included" de Python fais pencher la balance
      • [^] # Re: Depuis le début

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

        > Ruby et Python sont tous les deux tres lents.

        As-tu déjà essayé de ramper sur le ventre, sans t'aider des pieds et des mains ?

        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.