Journal Sortie de Python 3 alpha

Posté par .
Tags : aucun
0
1
sept.
2007
Python 3 (aka python 3000) est une refonte assez profonde du langage python, il est important de noter qu'il ne sera pas compatible avec la série des python 2.* (amis mainteneurs au boulot).
Au menu quelques changements fondamentaux sur le formats de certains objets (les chaînes de caractère en particulier) et tout plein d'autres choses que je vous invite à découvrir sur cette page: http://docs.python.org/dev/3.0/whatsnew/3.0.html
La feuille de route prévoit une sortie de la version finale en août 2008 ce qui vous laisse le temps de faire des mises à jour dans votre code pour être "Python3000-ready"

La nouvelle: http://mail.python.org/pipermail/python-list/2007-August/455(...)
La doc (en cours) : http://docs.python.org/dev/3.0/
Le téléchargement: http://python.org/download/releases/3.0/
  • # Python sur la voie du tout objet ?

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

    J'ai l'impression que Python 3 est en train de rejoindre ruby sur certains points, et ce point là en particulier, concernant les classes

    This is a series of changes to Python intended to remove most of the differences between built-in types and user-defined classes. Perhaps the most obvious one is the restriction against using built-in types (such as the type of lists and dictionaries) as a base class in a class statement.

    Traduction approximative :
    C'est une série de changements dans python pour supprimer la majeure partie des différences entre les types de base et les classes définies par l'utilisateur. Une des plus évidente est probablement l'impossibilité de dériver un type de base pour écrire une classe.

    Contrairement à ruby :

    class Price < int
    ...
    end

    J'ai l'impression que les objectifs de ces deux langages se rejoignent. Quelqu'un qui connaitrait les deux peut-il argumenter ?
    • [^] # Re: Python sur la voie du tout objet ?

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

      Je voudrais quand même savoir d'où vient la citation, parce qu'en l'état, soit c'est pour une très vieille version de python, soit il manque un contexte particulier. Sous python 2.2, plus ancienne version installée sur ma machine, sortie fin 2001, je peux parfaitement dériver la classe int:
      >>> class Price(int):
      ...     pass
      ...
      >>>
      • [^] # Re: Python sur la voie du tout objet ?

        Posté par . Évalué à 1.

        Je vais probablement passer pour un neuneu, mais quel est l'intérêt de créer une classe dérivée de int par exemple ?
        Je veux un vrai intérêt et pas seulement un intérêt théorique.

        NB: je ne connais pas python.
        • [^] # Re: Python sur la voie du tout objet ?

          Posté par . Évalué à 3.

          A mon avis ca permet de creer un nouveau type, ce qui permet d'eviter de melanger les patates et les carottes.

          exemple (en pseudocode):

          type Carotte = Int;
          type Patate = Int;

          Carotte c = Carotte(5);
          Patate p = Patate(3);

          Int total= c + p; //Impossible, erreur de compilation.

          Par opposition, si tu as

          Int c = 5;
          Int p = 3;
          Int total = c + p;

          la, ca marche.

          En general, creer de nouveaux types pour representer des donnees differentes est un bon style de programmation. Malheureusement, on ne peut pas faire ca avec un certain nombre de languages (dont C, car typedef ne cree pas un nouveau type mais juste un nouveau nom pour un type).
      • [^] # Re: Python sur la voie du tout objet ?

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

        Autant pour moi.
        La citation date de 2002, python 2.2.
      • [^] # Re: Python sur la voie du tout objet ?

        Posté par . Évalué à 3.

        Le nouveau système d'objet date justement de la 2.2, mais python a toujours gardé la rétrocompatibilité avec le modèle de la 2.0. Depuis, pour utiliser le nouveau modèle, soit on dérive d'"object", soit d'un des types de base ou autre de python. D'où l'héritage de "int" possible dans ta version de python.
  • # Autres sur Python 3000

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

    J'ai écrit un billet dans mon blog au sujet de Python 3000 :
    * Types bytes et str
    * Annotation des fonctions
    * Argument sous forme de mot-clé
    http://www.haypocalc.com/blog/index.php/2007/07/30/63-change(...)

    Y'a un autre gros changemetn que j'ai appris au passage : PEP 3119 qui introduit les classes abstraites qui sont similaires aux interfaces Java.
    http://www.python.org/dev/peps/pep-3119/

    Autre billet présentant les développements d'il y un mois :
    http://www.haypocalc.com/blog/index.php/2007/08/14/67-etat-d(...)

    --

    En ce qui concerne le code existant, un outil de conversion appelé « 2to3 » est disponible et fait 95% du boulot. Guido van Rossum conseille de ne pas toucher son code Python 2.x et de n'utiliser que l'outil de conversion. Python 3000 ne sera pas disponible avant 2008 (été 2008 ?).

    Je vous conseille quand même de commencer à :
    - utiliser a//b plutôt que a/b pour la division entière (car 2/1 donne 2.0 et non pas 2 dans Python 3000)
    - éviter de mélanger chaîne de caractère ('unicode') et chaînes d'octets ('str') car de toute façon c'est source de nombreux bugs. Il vaut mieux rester en Unicode le plus longtemps possible.

    Python 3000 vise à limiter les erreurs liées au langage. Exemple : 0666 est une erreur, il faut écrire explicitement 0o666 (forme octale). Ceci évite les erreurs quand l'utilisateur saisi un zéro en trop. Le mélange entre caractère et octet était aussi source de bug. Enfin, la fusion de int et long simplifient le code. Bref, Python 3000 c'est que du bon.

    Haypo
    • [^] # Re: Autres sur Python 3000

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

      Bof, ça devient difficile à comprendre et à coder pour un langage qui était facile d'accès pour les débutants.

      Note: Le score de mon post dépendra uniquement de la proportions de trolls ;)

      Envoyé depuis mon lapin.

      • [^] # Re: Autres sur Python 3000

        Posté par . Évalué à 3.

        Tu peux argumenter ?

        Un language non permissif et strict, est un avantage. C'est un avantage principalement pour les débutants. Certe, ça complique un peu l'apprentissage.

        Un développeur expérienté peut détecter les erreurs comme le mélange d'UNICODE avec du non UNICODE, etc...

        Pour un débutant c'est beaucoup plus dure. Si le compilateur/interpréteur donne un message d'erreur, même si le débutant ne comprent pas, il va sur un forum et demande de l'aide/explication. Sinon il est tout seul pour trouver son erreur. S'il va sur un forum en disant "ça ne marche pas", il n'aura pas d'aide. S'il y va avec "erreur ligne X : type incompatible", il aura de l'aide/explication.

        Le C++ est plus stricte que le C. Il est plus facile pour un débutant d'utilise le sous-ensemble C du C++ que le C (surtout si c'est le C K&B).

        Apprendre à programmer, ce n'est pas faire en sorte que le programme compile ou soit interpréter, c'est apprendre à faire des programmes qui marchent. Un language strict est un avantage quand on veut quelque chose qui marche.
        • [^] # Re: Autres sur Python 3000

          Posté par . Évalué à 2.

          Le souci est dans la définition du programme qui "marche". Pour certains, nombreux parmis les débutants, faire un programme qui "marche" c'est coder comme un goret un truc qui fait a peu prêt ce qu'on voulait de lui. Et il n'y arrivera peut être pas en python, donc pour lui il n'aura pas un programme qui "marche".

          Note que l'on est bien d'accord, pour moi un débutant qui réussi sont apprentissage via python est une excellente chose, par contre, je doute que tous y arriveront, parce que la simple idée qu'un langage puisse être très structuré, que cette structure est décrite et compréhensible si on la lit dans la doc est finalement quelque chose d'assez avancé dans l'apprentissage de la programmation. En effet la première approche est souvent "c'est comme ca donc je fait pareil" alors qu'en fait notre néophite ne fera pas exactement pareil parce qu'il ne sait pas que la structure est formelle (l'idée même de formel est au delà de ses connaissances !).

          Bref, sujet complexe, et même si je suis d'accord avec toi, mieux (pour le débutant) ne veux pas forcément dire plus simple. Je serais plutôt de l'avis que certains feraient mieux de s'abstenir de l'apprentissage de la programmation :)
        • [^] # Re: Autres sur Python 3000

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

          Évidemment qu'un langage strict, c'est mieux.
          Mais si php a eu autant de succès, c'est aussi à cause des "0"==false
          Beaucoup de gens n'ont pas le goût de bien programmer dès le début. Ils vont ce tourner vers d'autres langages.

          C'est peut-être pas plus mal.

          Envoyé depuis mon lapin.

          • [^] # Re: Autres sur Python 3000

            Posté par . Évalué à 1.

            ben y a aussi le coup de faire un programme juste pour des petits scripts.
            Peut etre que dans le cas du php c'est 'juste' pour faire des pages web du site familliale, et donc forcément la savoir structurer son code n'est pas la chose la plus importante pour eux.
            • [^] # Re: Autres sur Python 3000

              Posté par . Évalué à -1.

              PHP, c'est fait pour faire des petites pages web... Comme celle-ci ?
              http://www.facebook.com
              • [^] # Re: Autres sur Python 3000

                Posté par . Évalué à 4.

                php c'est fait ENTRE AUTRE pour faire des petites pages web.

                Alors tu peux faire des gros projet en php, tout comme tu peux aussi en faire entièrement en ASM ou entièrement en brainfuck.

                Les gros projets sont le plus souvent fait par des gens qui ont un minimum d'experience (ne serait ce l'exp gagné sur ce projet).

                Donc tu essaie de montrer quoi la ?
                • [^] # Re: Autres sur Python 3000

                  Posté par . Évalué à 2.

                  Je sais bien que PHP est fait pour faire des petits scripts (et j'aimerai pas avoir a m'en servir pour autre chose qu'un petit script d'ailleurs). Mais le fait est qu'aujourd'hui beaucoup s'en servent pour de gros projets (avec les problemes qui vont avec).
    • [^] # Re: Autres sur Python 3000

      Posté par . Évalué à 1.

Suivre le flux des commentaires

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