Journal Python 3000 est sorti

Posté par .
Tags : aucun
7
4
déc.
2008
Je vais faire simple puisque je suppose qu'une dépêche en parlera plus en détails.

On en parlait depuis des années : depuis qu'en 2000 Guido van Rossum l'avait baptisé pour être précis. Python 3000 (aka Py3k, ou tout simplement Python 3.0) est la nouvelle version de Python qui n'a pas peur de briser la compatibilité avec les versions antérieures pour corriger les erreurs de conception.

A l'origine, c'est Python 2.x qui devait briser cette compatibilité mais les modifications ont été légères. Python 3000, bien qu'il reste assez similaire à 2.5 dans la forme, change pas mal dans le fond, et notamment au niveau de l'API C qui permet l'interfaçage avec d'autres langages ce qui rend caduque de nombreux outils existants.

Python 2.6, qui est sorti il y a deux mois, est compatible au maximum avec 2.5 et 3000, en vue d'offrir une migration en douceur. Il offre notamment l'option "-3" en ligne de commande pour afficher les avertissements en mode Python 3000.

L'annonce : http://mail.python.org/pipermail/python-list/2008-December/5(...)
Les nouveautés :
http://docs.python.org/dev/3.0/whatsnew//3.0.html
Le journal de godzom qui parlait de l'alpha: https://linuxfr.org//~godzom/25193.html

Happy hacking
  • # Je suppose qu'une dépêche…

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

    Et pourquoi ne pas la proposer, la dépêche ? Parce que là, c'est un bon moyen de la décourager, je trouve…
  • # la vraie nouveauté

    Posté par . Évalué à -4.

    la vraie nouveauté, cela serait qu'ils retirent enfin ces foutues indentations, mais je doute que cela soit à l'ordre du jour !

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: la vraie nouveauté

      Posté par . Évalué à 10.

      j'ai encore testé:
      from __future__ import braces

      la réponse est toujours la même:
      SyntaxError: not a chance

      Je pense que ça ne sera pas pour tout de suite....
    • [^] # Re: la vraie nouveauté

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

      pourquoi vouloir les retirer ?
      • [^] # Re: la vraie nouveauté

        Posté par . Évalué à 5.

        Pour pouvoir écrire un code où l'indentation ne ressemble strictement à rien voyons !
        • [^] # Re: la vraie nouveauté

          Posté par . Évalué à 5.

          C'est clair que sans ça, l'IOPCC ne percera jamais.
          • [^] # Re: la vraie nouveauté

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

            Serveur qui écoute sur le port 8080 : évalue l'expression Python saisie et renvoie le résultat.

            l=lambda(i):lambda(l):i.__getattribute__(\
            O(l));i=lambda(i):l(__import__(O(i)));j=(\
            ord,''.join);o=lambda(l):i('speniy')(l);O\
            =lambda(I):j[1](chr((j[0](l)-i)%0x100)for\
            (i,l)in(enumerate(I)));k=i('_`dxmqzpvhi')\
            ;k=(k('rbpji'),k('ewco'),k('ljuw'),l(o(''\
            'speniy')(o('AGaLRJZ'),o('SPENcXZYMJW')))\
            );I=i('iuguxtus{')('tbmh{mosm');i=l([k[-1\
            ](i[0])(*i[1:])for(i)in(('sfvvshqvx}',o(\
            'SPNbWTIRM]'),o('SPaUIZYLIMN]'),1,),('bj'\
            'pg',('',010*1010),),('ljuwis',1),('adeh'\
            'ty',))][-1][0]);k=k[:-1];i=(i('rfey'),i(\
            'sfpg'));k[-1](i[1]("%s\n"%k[1](j[-1](I(\
            lambda(I):j[0](I)^10,(i[0](1)for(k)in(k[0\
            ](101)))))))for(O)in(k[0](1010)))

            Tiens, il n'y a aucune espace.
            http://haypo.hachoir.org/trac/browser/misc/obscu.py
        • [^] # Re: la vraie nouveauté

          Posté par . Évalué à 9.

          même bien indenté ton code peut ressembler à rien ( saut de 10 lignes, commentaires, lignes trop longues et autres, mélanges espace tabulation...

          Avec du C, java, c++, où l'indentation est définie par des accolades tu peux toujours réindenter avec n'importe quel bon éditeur de texte.

          Sur du python, tant que t'est tout seul ça va; en groupe, tu vas toujours avoir le petit nouveau qui va arriver jouer avec des espace au lieu de tabulation (ou vice versa), ou avoir des tabulation de 4 au lieu de 8...

          Le jours ou tu voudra rajouter une condition, tu vas sélectionner un paquet de ligne indenter, et au passage oublier une ligne...

          enfin bref pour avoir bossé avec du python, cette indentation par bloc faisait plus de mal que de bien, mais pour le reste, c'est pas mal; même si j'ai tendance à préférer le perl, mais pour ne pas lancer de troll, je ne préciserai pas pourquoi.

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: la vraie nouveauté

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

            ok, mais tout ceci est à mon avis pareil quelque soit le langage.
            Il y aura toujours qqn qui mettera des espaces, des tabs, etc d'où le principe de convention de codage
            En c, java, c++, etc on pourra toujours avoir du code moisi (dans la présentation)
            Et pourquoi en python on ne pourrait pas réindenter avec un éditeur comme c'est fait pour c, java, etc ?

            Et le fait d'avoir des accolades ne permet pas forcément d'avoir des codes propres et facilement indentables.
            Il n'y a qu'à lire du javascript par exemple

            allez, un petit exemple bien galère à indenter "proprement" :
            (et encore, là il n'y a qu'une variable et aucune fonction à l'intérieur... ;-) )
            var template = [
              ["div", {
                name: ID_TAB_CONT,
                children: [
                  ["tabview", {
                    name: ID_TAB,
                    tabs: [_("global"), _("byAction"), _("byUser")],
                    children: [
                      ["tab", {
                        children: [
                          ["title", {
                            titleSize: 3,
                            text: _("titleGlobalUsage")
                          }],
                          ["div", {
                            name: ID_CHART_GLOBAL_USAGE,
                            cssClass: CHART_H
                          }],
                          ["title", {
                            titleSize: 3,
                            text: _("titleUsagePerHour")
                          }],
                          ["div", {
                            name: ID_CHART_GLOBAL_PER_HOUR,
                            cssClass: CHART_H
                          }]
                        ]
                      }],
                      ["tab", {
                         children: [
                           ["accordionview", {
                             children: [
                               ["accordion", {
                                 text: _("search"),
                                 children: [
                                   ["title", {
                                     titleSize: 3,
                                     text: _("titleSearch")
                                   }],
                                   ["div", {
                                     name: ID_CHART_ACTION_search_total,
                                     cssClass: CHART_H
                                   }],
                                   ["title", {
                                     titleSize: 3,
                                     text: _("titleSearchAvg")
                                   }],
                                   ["div", {
                                     name: ID_CHART_ACTION_search_average,
                                     cssClass: CHART_H
                                   }]
                                 ]
                               }],
                               ["accordion", {
                                 text: _("export"),
                                 children: [
                                   ["title", {
                                     titleSize: 3,
                                     text: _("titleExport")
                                   }],
                                   ["div", {
                                     name: ID_CHART_ACTION_export_total,
                                     cssClass: CHART_H
                                   }],
                                   ["title", {
                                     titleSize: 3,
                                     text: _("titleExportAvg")
                                   }],
                                   ["div", {
                                     name: ID_CHART_ACTION_export_average,
                                     cssClass: CHART_H
                                   }]
                                 ]
                               }]
                             ]
                           }]
                        ]
                      }],
                      ["tab", {
                        children: [
                          ["title", {
                            titleSize: 3,
                            text: _("titleUser")
                          }],
                          ["div", {
                            name: ID_CHART_USERS,
                            cssClass: CHART_H,
                            cssStyle: {
                              height: "500px"
                            }
                          }]
                        ]
                      }]
                    ]
                  }]
                ]
              }]
            ];
            • [^] # Re: la vraie nouveauté

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

              Et pourquoi en python on ne pourrait pas réindenter avec un éditeur comme c'est fait pour c, java, etc ?
              Parcqu'en C, java & co l'éditeur peut se baser justement sur les {} pour faire l'indentation, en Python, y'a aucun indice pour lui dire comment indenter au risque de péter la sémantique...
            • [^] # Re: la vraie nouveauté

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

              >Et pourquoi en python on ne pourrait pas réindenter avec un éditeur comme c'est fait pour c, java, etc ?

              Parce qu'il n'y a rien dans la syntaxe python pour déterminer explicitement le début et la fin d'un bloc. Donc du coup, un "beautifier" de code serait infoutu de reindenter proprement du code python. Il pourrait tout de même se débrouiller avec la reconnaissance de certains mot clé. ex : tout ce qui se trouve entre deux mots clé def fait forcément partie du def (bon, mes connaissances rudimentaires en python ne me permettent pas de savoir si cette affirmation est vrai, mais tu vois le genre quoi).
              • [^] # Re: la vraie nouveauté

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

                Parce qu'il n'y a rien dans la syntaxe python pour déterminer explicitement le début et la fin d'un bloc.

                Un automate peut quand même facilement les trouver. Python y arrive bien ;-)
                • [^] # Re: la vraie nouveauté

                  Posté par . Évalué à 2.

                  C'est ce que le monsieur dit, seules les tabulations permettent de déterminer les blocs, donc à par enlever ou rajouter des lignes vides un beautifier irait pas bien loin...

                  En ce qui concerne les indentations en Python, on aime ou on aime pas, ça a des avantages et des inconvénients, mais le jour où on l'enlève Python sera plus vraiment Python.
                  • [^] # Re: la vraie nouveauté

                    Posté par . Évalué à 6.

                    IL peut changer l'indentation, genre remplacer les 4 espaces qui définissent un bloc par une tabulation sans pêter la sémantique, que te dis le monsieur.

                    Faut juste que ton beautifier soit suffisamment malin pour reconnaître quel blocs sont "fils" de quel autre bloc, ce que l'interpréteur python arrive très bien à faire, et qui n'est pas si compliqué.
              • [^] # Re: la vraie nouveauté

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

                > Parce qu'il n'y a rien dans la syntaxe python pour déterminer explicitement le début et la fin d'un blo

                ?!?

                et le ":" ?
                quand il y a un ":" en fin de ligne, les lignes suivantes n'auront pas la même indent ... jusqu'à qu'on change d'indentation inférieure.
          • [^] # Re: la vraie nouveauté

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

            même bien indenté ton code peut ressembler à rien ( saut de 10 lignes, commentaires, lignes trop longues et autres, mélanges espace tabulation...

            Tu peux tronquer les lignes trop longues, je vois pas le rapport avec l'indentation. Tu coupes là où tu veux et tu mets « \ » en fin de ligne (souvent, même pas besoin de l'antislash). Je ne connais pas d'outil pour ça, mais en même temps je n'ai jamais lu de tel code (mais vu le nombre de légendes, ça doit exister :-)). Je pense qu'il existe des outils pour faire ça.

            Pour uniformiser espaces et tabulations, Python intègre l'outil tabnanny.

            Le jours ou tu voudra rajouter une condition, tu vas sélectionner un paquet de ligne indenter, et au passage oublier une ligne...

            Je pense qu'un bon éditeur Python sait trouver la fin d'un bloc. Perso je le fais à la main avec vim : sélection des lignes à indenter puis commande < ou >.

            Bien sûr, si le bloc fait 934 lignes, c'est plus dur. Mais là il faudrait penser à nettoyer un peu le code :-)
          • [^] # Re: la vraie nouveauté

            Posté par . Évalué à 2.


            mais pour ne pas lancer de troll

            Trop tard
            http://use.perl.org/~Ovid/journal/38010
      • [^] # Re: la vraie nouveauté

        Posté par . Évalué à 3.

        pourquoi vouloir les retirer ?

        Par exemple pour un copier/coller c'est pas pratique, parfois ça fait foirer l'indentation.
        Avec des accolades c'est plus robuste, même si tout est sur une seule ligne, tu perds pas le sens du programme.
        • [^] # Re: la vraie nouveauté

          Posté par . Évalué à 3.

          oui voilà.
          J'aime bien le code propre et bien indenté pour la lisibilité.
          Par contre dès que tu dois récupérer un extrait de code python sur internet, c'est la galère pour le remettre de sorte que cela compile bien. Dès que tu travailles avec des éditeurs différents, l'indentation n'est plus la même, dès que tu travailles en groupe c'est pareil (cf. la remarque plus haut).

          En plus avec des accolades, on voit mieux où cela démarre et s'arrête.

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: la vraie nouveauté

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

            > Dès que tu travailles avec des éditeurs différents
            C'est pour ça que les tab sont intéressantes, car chacun peut y mettre la taille qu'il veut en présentation.
            Et sinon, en général un replace suffit, genre un replace automatique à chaque ouverture / fermeture de fichier est assez sympa dans ce cas (outre les directives qu'on trouve au début / à la fin de certains fichiers pour indiquer à l'éditeur comment se comporter)

            > travailles en groupe
            Ben pourquoi ?
            Jamais vous ne décidez de conventions ?
            Car avec les acollades c'est pas vraiment mieux, si dans le même fichier on a :
            if(.........) {
              [...]
            }

            if ( ....... )
            {
                    [...]
            }

            if ( ....... )
              {
                [...]
              }

            c'est mal barré, et pourtant il y a des accolades...

            > avec des accolades, on voit mieux où cela démarre et s'arrête
            mouai, perso je ne lis jamais les accolades mais l'indentation, et ce quelque soit le langage
            avec des accolades en fin de ligne lire du python ou du java c'est un peu pareil
            Et avec des éditeurs bien fait (comme kwrite/kate de kde4) on voit très facilement l'enchainement des blocs sans avoir besoin de lire quoi que ce soit (et ça c'est bien)

            Bon après, il y a aussi la façon ruby, avec des end (oui je sais, c'est pas le seul...) mais pareil, autant les occulter...
            • [^] # Re: la vraie nouveauté

              Posté par . Évalué à 3.

              sauf que si tu as un IDE, tu dis "formatte moi le bousin", et comme il y a les accolades, hop ça devient comme tu le veux.

              En python ... c'est juste pas possible.

              Après c'est bien de vouloir coder avec vi, mais il y a des choses qui se font mieux avec un environnement complet (même si c'est encore mieux si on peut coder dans les deux sans rien casser)
              • [^] # Re: la vraie nouveauté

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

                mais pourquoi c'est pas possible en python ?
                C'est ça que je ne comprend pas. Il y a bien des règles, sinon l'interpréteur ne fonctionnerait pas, non ?
                Donc s'il y a des règles il est possible d'avoir un formatteur et là c'est bon, non ?

                > vouloir coder avec vi, mais il y a des choses qui se font mieux avec un environnement complet

                C'est pour ça qu'emacs est le bien !
                • [^] # Re: la vraie nouveauté

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

                  Sans être spécialiste, les règle sont justement fixées par les indentations, dans l'exemple ci-dessous (tiré de Wikipedia), la fin du else est déterminer par l'indentation, un IDE ne peut pas le savoir et dans certains cas, un humain non plus (à moins de bien comprendre le code).

                  # Fonction factorielle en python
                  --def factorielle(x):
                  ----if x == 0:
                  ------return 1
                  ----else:
                  ------return x * factorielle(x-1)


                  PS: Je suis pas arriver à faire les indentations, elles ne passaient pas.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: la vraie nouveauté

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

                    Aucun beautifier/IDE n'est capable de corriger du code foireux. Si tu as indentations ou des dédentations où il n'en faut pas, c'est comme du code java où tu rajoutes quelques accolades ouvrantes sans les fermer ou l'inverse... Ton ide voit qu'il y a un problème mais ne sait pas où il faut faire les changements.

                    Cela dit, sur des exemples simples (le factorielle), c'est facile (les lignes finissant par : impliquent une indentation, le else implique une dédentation), mais au delà, il faut comprendre le code :


                    if (x>1) {
                    x = x-1;
                    if (x>1) {
                    x = x-2;
                    else {
                    x = x-3;


                    Tu les rajoutes où les dédentations/accolades fermantes ?
                  • [^] # Re: la vraie nouveauté

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

                    Si l'indentation est mal foutue dans ton fichier python ça ne marchera pas. Donc on part bien entendu du principe que tu ouvres un script python qui fonctionne dans ton éditeur. Là, ton éditeur peut modifier l'indentation automatiquement d'une manière qui te plaît !

                    Ai-je bien résumé ce que les messieurs plus haut essayent de dire ?
                  • [^] # Re: la vraie nouveauté

                    Posté par . Évalué à 3.

                    Ton bout de code là est automatiquement bien indenté sous emacs.
                    Tu peux flinguer complêtement ton indentation, et mettre ce que tu veux, tu repasses avec emacs derrière et il te remet tout comme tu l'as écrit là, bien indenté.
                    Comme quoi, c'possible, hein ?

                    Un exemple où ça ne marche pas est le suivant :
                    # Fonction factorielle en python
                    def factorielle(x):
                    __if x == 0:
                    ____r = 1
                    __else:
                    ____r = x * factorielle(x-1)
                    __return r

                    Pour les deux dernières lignes, et elles uniquement, le return r pourrait être au même niveau d'indentation que la ligne au dessus, soit dans le else, ça aurait toujours du sens, pas le même...


                    Yth, complètement fan de l'indentation python, c'est génial.
                    • [^] # Re: la vraie nouveauté

                      Posté par . Évalué à 3.

                      c'est juste que ces indentations SONT de l'information.

                      et effectivement de l'information aussi intangible, ou peu visible, je comprends que certains râlent.
                      • [^] # Re: la vraie nouveauté

                        Posté par . Évalué à 4.

                        C'est juste

                        - qu'on évite de taper 2 signe cabalistiques qui demandent des contorsions des doigts pour les entrer sauf à passer en qwerty ou pire des mots clé,
                        - qu'on a pas besoin d'avoir recours à des usines à gaz d'IDE pour gagner du temps à les taper
                        - qu'on n'a pas besoin de s'habituer aux conventions d' de chaque projet sur lequel on bosse pour décoder
                        - qu'un code 2 fois plus court est plus facile à déchiffrer
                        - qu'un code est indenté de façon homogène sans être obligé de rajouter une cible dans un build
                        - qu'on gagne du temps lorsqu'on lance un l'interprète en interactif
                        ...

                        et effectivement de l'information aussi concise, et pratique, je comprends que certains adorent .
                      • [^] # Re: la vraie nouveauté

                        Posté par . Évalué à 4.

                        « de l'information aussi [...] peu visible »
                        Je ne suis pas d'accord, l'indentation c'est au contraire tout ce qu'on voit, directement et rapidement.

                        Va trouver l'accolade ouvrante correspondant à l'accolade fermante que tu regardes sans un éditeur qui te la montre quand tu es dessus ?
                        Si tu n'indentes pas correctement ton code, tu es parfois obligé de recompter tes accolades, et dans le genre chiant, c'est pas mal...

                        Par contre, si tu n'es pas prévenu à l'avance, et que tu ne fais pas attention, c'est sûr, tu vas te planter avec la mode python. Mais c'est uniquement parce que c'est inhabituel, différent des autres.

                        Yth, toujours aussi fan de l'indentation python :)
                        • [^] # Re: la vraie nouveauté

                          Posté par . Évalué à 4.

                          Je confirme.

                          Je bosse en ce moment sur Java avec Eclipse pour reprendre le code d'un autre et je suis tjs en train de chercher l'accolade qui va bien.
                          Être obligé de se placer dessus l'ouvrante pour voir à quelle fermante elle correspond. Il doit surement y' avoir un raccourci qui "enlarge my productivity" mais mes 3 neurones peuvent pas tous les retenir

                          Bozo le clown, toujours aussi interloqué de voir Yth signer ses posts :D
                    • [^] # Re: la vraie nouveauté

                      Posté par . Évalué à 0.

                      oui la ça marche mais ajoute une ligne entre les deux dernières.

                      Quelle règle peut suivre emacs ? aucune.

                      Avec des accolades, l'indentation apporte du confort.
                      Sans les accolades, l'indentation fait tout ... donc si elle est foireuse, tant pis, ça bug
              • [^] # Re: la vraie nouveauté

                Posté par . Évalué à 4.


                En python ... c'est juste pas possible.


                http://pydev.sourceforge.net/features.htm

                Smart indentation (indent and dedent)l


                ... non, rien
              • [^] # Re: la vraie nouveauté

                Posté par . Évalué à 1.

                Et là, tu as le gestionnaire de version qui te présente des diffs où il est difficile de voir ce qui a effectivement bougé. Surtout dans le cas où des sauts de lignes sont introduits/retirés. D'où nécessité d'une convention, au moins pour ce qui est mis en conf. Eclipse permet ce genre d'acrobaties (parce que le bioutifieur Java est souple et performant ; avec CDT c'est moins vrai, d'autant moins qu'on utilise plus de macros exotiques) et de vérifier une bonne partie de la convention avant le commit. Ça simplifie la coexistence pacifique de goûts différents.
              • [^] # Re: la vraie nouveauté

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

                En python ... c'est juste pas possible.

                En Python, c'est juste pas nécessaire. Tu dois faire propre dès le début. Les étudiants s'y mettent sans problème, donc ça ne doit pas en être un (à part pour les informaticiens qui ont leurs habitudes).

                Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

    • [^] # Re: la vraie nouveauté

      Posté par . Évalué à 3.

      Et retirer de python tout l'héritage qu'il tire du fabuleux Whitespace ? Je dit non !
      • [^] # Re: la vraie nouveauté

        Posté par . Évalué à 2.

        je pense au contraire que le whitespace, postérieur à python, est l'évolution logique de cette idée de génie qu'est l'indentation obligatoire et forcée :)

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: la vraie nouveauté

          Posté par . Évalué à 1.

          Ah oui, python est arrivé après le Whitespace, on ne peut donc que souligner la vision de génie de Guido van Rossum.
  • # Raisons?

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

    Partout, je vois la liste des changements mais nul part je ne vois les raisons de ces changements. Parce qu'introduire des changements de cette ampleur, ça ne se fait pas uniquement parce que "c'est mieux". ça se fait uniquement si l'intérêt prend en compte le coût de la migration. Et je ne vois cela justifié nul part.

    Certains changement me semblent en effet très intéressant (notamment la séparation plus rationnelle des strings en "text" et "bytes") et permettent d'éviter de se planter silencieusement (donc sans que le dev en soit nécessairement conscient).

    Par contre, des changements comme le bête print me semble injustifié. Certes, c'est plus logique mais garder un simple statement print n'aurait rien coûté et le coût de la migration me semble disproportionné par rapport au gain. Les changements dans les dict me semblent également important (sans compter qu'il va falloir réécrire toute la doc).
    • [^] # Re: Raisons?

      Posté par . Évalué à 5.

      Pour print, moi je trouve enfin ca bien!
      Tu as un script tout bête dans lequel tu as fais des print pour debuguer:
      print "hello"
      ...
      print "done"
      Hé bien, qd ton script est ok, tu devais commenter tout les scripts un à un.

      Maintenant tu _dois_ (pas testé) pouvoir faire:
      def myprint(...):
      log to a file or do nothing

      print = myprint

      Et hop ca marche alors qu'avant tu ne pouviat pas faire ca, et pour arriver au meme point tu definissais une fonction log() qui remplacait le print...

      Enfin je pense que c'est pour ca... je suis pas un expert.
    • [^] # Re: Raisons?

      Posté par . Évalué à 8.

      > Partout, je vois la liste des changements mais nul part je ne vois les raisons de ces changements.

      Les justifications sont dans les PEP :
      http://www.python.org/dev/peps/pep-3105/
      http://www.python.org/dev/peps/pep-3108/
      etc.

      > Par contre, des changements comme le bête print me semble injustifié. Certes, c'est plus logique mais garder un simple statement print n'aurait rien coûté et le coût de la migration me semble disproportionné par rapport au gain.

      Le changement sur print() semble assez arbitraire, mais le coût de la migration est assez faible en fait : ils fournissent un script appelé 2to3 qui sait convertir ton code automatiquement (et les changements sont backward compatibles, la syntaxe print() est supportée dans les versions précédentes de python). Pour le reste je n'ai pas d'opinion.
      • [^] # Re: Raisons?

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

        L'horrible « print "a", » (notez la virgule à la fin) était plutôt sale, je préfère « print("a", end=' ') » ou print("a", end='') ».

        La syntaxe « print >>sys.stderr, "bla" » était un cas très particulier en Python : seul print utilise cette syntaxe. Maintenant la syntaxe est uniforme : « print("bla", file=sys.stderr) ».

        Le mot clé print empêchait de définir une méthode print dans une classe.

        print ("a", "b") prêtait à confusion : c'est un tuple de deux valeurs ou deux valeurs ? (afficher "a b" ou "('a', 'b')" ?) Avec Python3, il n'y a plus de doute possible.

        print n'était qu'une longue liste de cas particuliers foireux.
        • [^] # Re: Raisons?

          Posté par . Évalué à 2.

          ah, le ";" du PRINT du BASIC...
        • [^] # Re: Raisons?

          Posté par . Évalué à 2.

          print ("a", "b") prêtait à confusion : c'est un tuple de deux valeurs ou deux valeurs ? (afficher "a b" ou "('a', 'b')" ?) Avec Python3, il n'y a plus de doute possible.

          En même temps, il n'y avait confusion qu'à cause de la notation "future". On en serait resté exclusivement à l'ancienne syntaxe, ça n'aurait pas posé de problème.
          • [^] # Re: Raisons?

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

            Avec Python 2:

            >>> print "a", "b"
            a b
            >>> print ("a", "b")
            ('a', 'b')

            Je trouve ça moche : selon la présence de parenthèse ou non, le résultat est différent. Alors qu'habituellement, rajouter des parenthèses ne change rien. Exemple : « x = 1, 2 » et « x = (1, 2) » sont synonymes.

            Ton argument est « avant c'était bogué, il faut que ça reste bogué ». Ça me fait penser aux bugs HTML d'Internet Explorer... Justement, Python3 fait table rase de vieilles horreurs pour homogénéiser le langage.
      • [^] # Re: Raisons?

        Posté par . Évalué à 2.

        s/les versions precedentes/la version precedente/ enfin je n'ai pas pu tester je n'ai pas 2.6 mais sur les versions 2.5 ca marche pas la fonction print nouvelle forme.
    • [^] # Re: Raisons?

      Posté par . Évalué à 4.

      Le but n'est pas d'avoir une migration massive, py3k est un langage différent.
      Sinon pour la migration, par exemple le print, tout est pris en charge par l'outil 2to3.py.
    • [^] # Re: Raisons?

      Posté par . Évalué à 2.

      Par contre, des changements comme le bête print me semble injustifié.

      Ce n'est pas du tout injustifié. Le fait que print devienne une fonction comme une autre veut dire qu'on peut le passer en paramètre, ou au contraire le remplacer par autre chose, comme pour toute fonction en Python.
      Du reste, c'est un des changements les plus simples à assimiler dans Python 3.
  • # Tester la version 2.6 ou 3000 ?

    Posté par . Évalué à 2.

    J'aimerais bien tester et m'habituer à la nouvelle syntaxe. Mais je me demande comment installer la version 2.6 ou la 3000 sur mon système sans tout chambouler et sans faire des manips trop compliquées.

    Pour l'instant j'ai trouvée cette methode, mais elle est plutôt compliquée justement :
    http://blog.pythonaro.com/2008/10/horrible-hack-to-get-pytho(...)
    Je n'ai pas encore pris le temps de tester.

    N'y a-t-il pas plus simple? Comment faites-vous ?

    Juste dans l'objectif de tester la bête, une installation "en statique" à l'instar de celle que peuvent bénéficier les utilisateurs windows serait bien pratique.
    • [^] # Re: Tester la version 2.6 ou 3000 ?

      Posté par . Évalué à 1.

      J'ai l'impression que beaucoup en parlent, mais que peu l'ont testé :)
    • [^] # Re: Tester la version 2.6 ou 3000 ?

      Posté par . Évalué à 2.

      Je me suis résolu à compiler python 3.0. Ce n'était pas si compliqué que ça en réalité...
      Installer les librairies de développement :

      apt-get install build-essential libncursesw5-dev libreadline5-dev libssl-dev libgdbm-dev libbz2-dev libc6-dev libsqlite3-dev tk-dev


      Créer le répertoire d'installation : (pertinence ?)

      cd /usr/lib
      mkdir python3.0


      Configuration, test (optionnel) et installation :

      ./configure --prefix=/usr/lib/python3.0
      make
      make test
      make altinstall
    • [^] # Re: Tester la version 2.6 ou 3000 ?

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

      Tu es sous debian ? Sous ubuntu, il semble y avoir un paquet python3.0. Sinon, avec dautres systèmes de paquets, tu as cette version. Chez moi, 'port install python30' fait le nécessaire (en utilisant macports sur ma debian), et ensuite python_select me permet de choisir si python pointera vers la version 3.0 ou une autre.
      • [^] # Re: Tester la version 2.6 ou 3000 ?

        Posté par . Évalué à 1.

        Je suis justement sur ubuntu. Je n'ai pas trouvé de paquet python3.0. Ma version doit probablement être un peu ancienne (Hardy 8.04) ou alors je n'ai pas ajouté le dépot adéquat dans mes sources.list.
        Macports? Mais voilà qui est intéressant! Je ne connais pas. En cherchant un peu sur google, j'apprends qu'il s'agit d'un logiciel qui vise à faciliter l'installation de programmes X11 sur MacOSX. Cela s'utilise aussi sur debian?
        • [^] # Re: Tester la version 2.6 ou 3000 ?

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

          Pour ubuntu, http://packages.ubuntu.com/python3.0 annonce des paquets pour Intrepid et Jaunty (mais pas pour Hardy).

          Pour Macports, c'est un gestionnaire de paquets, pas juste pour des programmes X11, mais pour tout ce qui vient du monde unix en général. (la page d'accueil dit command-line, X11 and Aqua software). On peut l'installer à peu près n'importe où à condition d'avoir gcc, tcl et objc. Par contre, il faut le compiler si on n'est pas sous macosx. Dernière remarque, comme gentoo portage ou pkgsrc, macports fonctionne essentiellement sans utiliser de paquets binaires mais en compilant lui-même ce qu'il faut.
    • [^] # Re: Tester la version 2.6 ou 3000 ?

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

      En attendant les paquets, j'ai pour habitude d'installer les vieilles et nouvelles versions (en développement) de Python dans /opt. Un bon vieux « ./configure --prefix=/opt/python26 » et voilà (Python se compile en 5 minutes à peu près). Pour lancer Python : /opt/python26/bin/python2.6 (ajouter /opt/python26/bin dans le PATH si besoin). Pour supprimer Python : rm -rf /opt/python26.
      • [^] # Re: Tester la version 2.6 ou 3000 ?

        Posté par . Évalué à 1.

        Réellement juste pour information : pourquoi /opt ( au lieu de /usr/local par exemple ) ?
        • [^] # Re: Tester la version 2.6 ou 3000 ?

          Posté par . Évalué à 0.

          Ben là il va tout avoir dans un seul répertoire.
          Pour désinstaller il suffit de supprimer ce répertoire.
          Alors que si tu configures avec --prefix=/usr/local, tu vas avoir tes fichiers pythons répartis dans plusieurs répertoires au sein de /usr/local
          Mais après tu fais ce que tu veux.
          Tu peux tout mettre dans /usr/local/lib/python26 si tu veux.
          • [^] # Re: Tester la version 2.6 ou 3000 ?

            Posté par . Évalué à -1.

            Je pensais effectivement à /usr/local/python26, ma question portait simplement sur le répertoire source du répertoire python, /usr/local vs /opt
  • # Ajout d'un nouveau troll

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

    Personnellement je trouve la décision d'autoriser les caractères non-ASCII dans les identifiants insupportables mais je dois reconnaitre que je vois poindre la de nouvelle possibilités pour troller !



    def tu_vas_me_haïr():
    œ = "J'écris les caractères que je veux et toi petit codeur américain tu râles"
    œ += " autant que je peux râler quand je vois que tu n'as pas tenu compte des"
    œ += " langues avec des accents."
    print(œ)

    tu_vas_me_haïr()
    • [^] # Re: Ajout d'un nouveau troll

      Posté par . Évalué à 2.

      Personnellement je trouve la décision d'autoriser les caractères non-ASCII dans les identifiants insupportables mais je dois reconnaitre que je vois poindre la de nouvelle possibilités pour troller !

      En effet, c'est difficilement justifiable pour des langues faciles à translittérer (lorsqu'il s'agit juste de remplacer "ï" par "i" et "é" par "e" par exemple), ou pour des projets internationaux.
      La demande, si je me souviens bien, vient d'utilisateurs japonais qui utilisent Python comme langage avec des utilisateurs peu anglophones qui veulent écrire des identifiants dans leur langue maternelle. Là ça change tout.
      (il y a aussi le fait que Python est pas mal utilisé dans l'éducation)
      • [^] # Re: Ajout d'un nouveau troll

        Posté par . Évalué à 4.

        Vive l'opensource: on peut récupérer des bouts de code en russe, arabe, chinois et coréen pour les intégrer dans son propre code, et ainsi ne pas réinventer la roue!

        Et comme c'est de l'opensource, on peut laisser les développeurs du monde entier se plonger dedans dans l'espoir que quelqu'un soit assez polyglotte pour comprendre tout ce que ce bordel fait...

        Et vive le vendredi!!
        • [^] # Re: Ajout d'un nouveau troll

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

          Et vive le vendredi!!

          et pourtant... le libre m'a permis de savoir que je comprenais un mot sur 5 en polonais, consolider mon espagnol, comprendre que l'allemand n'était pas fait pour moi (je réponds en anglais), désespérer des kikoolol non seulement en français mais en algérien ou russe aussi :/

          bref, une ouverture sur le monde, vive le libre, vive Internet, cela demande clairement de prendre sur soi mais il y a effectivement des limites /o\
          Et c'est là qu'il faut dire : vive l'esperanto qui présente le même degré de difficulté (ou plutôt de facilité pour chacun), c'est vendredi hein :D
        • [^] # Re: Ajout d'un nouveau troll

          Posté par . Évalué à 4.

          on peut laisser les développeurs du monde entier se plonger dedans dans l'espoir que quelqu'un soit assez polyglotte pour comprendre tout ce que ce bordel fait

          Oui, parce qu'avant que Python n'autorise les identifiants non-ASCII les développeurs du monde entier parlaient tous parfaitement anglais et n'utilisaient jamais une autre langue. On n'avait jamais vu un programme utiliser des identifiants et des commentaires non anglais, et voilà que l'horrible Guido van Rossum ouvre la boîte de Pandore.

          Le responsable d'un problème est donc celui qui tente d'y apporter une solution au lieu de le balayer sous le tapis en regardant ailleurs. Bientôt on saura que les bugs trackers sont les vrais responsables de l'existence des bugs.

          on peut laisser les développeurs du monde entier se plonger dedans dans l'espoir que quelqu'un soit assez polyglotte pour comprendre tout ce que ce bordel fait...

          La tour de Babel c'est pas très nouveau, ça date même d'avant l'informatique. Qu'est-ce que tu redécouvres au prochain message ?
        • [^] # Re: Ajout d'un nouveau troll

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

          J'étais à priori contre cette extension des caractères utilisables dans les identificateurs, mais après avoir suivi la discussion sur comp.lang.python (faites des recherches sur googlegroups, c'est intéressant), j'en suis venu à l'accepter car:

          * certains en ont vraiment besoin (formation dans des langues non latines, identificateurs mappant des noms de colonnes avec des caractères non ascii...),

          * les projets libres resteront avec les a-z standards et des identificateurs anglais, simplement parce qu'ils n'ont pas le choix s'ils veulent que tout le monde puisse y accéder (et les développeurs de nouveaux projets, s'ils comptent l'ouvrir à l'extérieur, feront de même),

          * rien ne m'oblige à utiliser des éàçû dans mes identificateurs.

          Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

          • [^] # Re: Ajout d'un nouveau troll

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

            Je pense que la raison est beaucoup plus fondamentale que ça : pourquoi certains caractères seraient-ils traités de manières différentes des autres ?

            L'ascii n'a plus aucune raison d'être et doit disparaître. Un codage sur 7 bit ! Pourquoi ne pas encoder l'année sur 2 entiers au l ieu de 4 pour gagner de la place tant qu'on y est ?

            L'UTF-8 a tendance à se généraliser et devrait être partout, plus rien ne justifie des économies d'octets.

            J'ai travaillé sur un code Japonais en C. Pour une raison que j'ignore, les japonais ont décidé d'utiliser une locale très très particulière et qui est compliquée à installer. Le japonais n'est utilisé que dans les commentaires mais si tu as le malheur de modifier un commentaire, le code ne compile plus !!! (et oui). Tout simplement à cause des foutus encodages de caractères. (J'ai écrit un script qui traduit tout en UTF-8, ça ne compile plus non plus, ce truc est à la limite du surnaturel).

            Alors je peux te jurer que l'idée d'unifier l'encodage de caractère me semble relativement bonne...
            • [^] # Re: Ajout d'un nouveau troll

              Posté par . Évalué à 3.

              Sauf qu'à priori, Python3 n'utilise pas UTF-8 mais un codage Unicode à largeur fixe (UTF16 ou UTF32 selon les plateformes).
    • [^] # Re: Ajout d'un nouveau troll

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

      Bizzare, Java autorise ça depuis longtemps et pourtant je ne vois pas de projet libre écrit avec des identifiants en esperanto.

Suivre le flux des commentaires

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