Sortie de Python 3.0 version finale

Posté par . Modéré par j.
Tags :
24
5
déc.
2008
Python
Le 3 décembre 2008, la version finale du langage interprété Python est sortie en version 3.0, après deux Release candidates. Cette version représente une évolution majeure du langage, brisant la compatibilité avec les versions précédentes pour corriger les erreurs de conception.

Selon Haypo, le changement majeur de Python3 est le passage intégral à Unicode : par défaut les fichiers sont ouverts en mode texte en Unicode, un script Python est en UTF-8 (Unicode), on peut utiliser des identifiants en Unicode (libre à vous d'écrire en japonais, français ou anglais, après ça dépend avec qui vous souhaitez travailler), et utilisation d'Unicode dans la grande majorité des modules (la bibliothèque standard).

Pour celles et ceux qui s'interrogeraient quelle version de la 2 (2.6) ou de la 3 (3.0) ils devraient choisir, il est préférable de commencer par la 2 car de nombreux modules additionnels sont directement disponibles et testés pour cette version. Ensuite avec l'outil 2to3, il est possible de tester son code avec la version supérieure. On peut noter que quelques améliorations prévues pour Python 3 ont été rétropropagées dans Python 2.6, permettant une transition plus facile.

Python 3.0 a pris beaucoup de retard sur son planning. L'équipe Python a préféré corriger tous les bugs plutôt que de sortir une version boguée qui dégoûterait les gens de Python 3.

NdM : Merci à Haypo pour son journal publié précédemment à ce sujet
  • # Traduction

    Posté par . Évalué à 10.

    «rétropropagées », superbe, je ne l'avais jamais entendu (lu). Je trouve que ça sonne très bien.
    • [^] # Re: Traduction

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

      Était-ce faire preuve de bravitude que de l'utiliser ?
      • [^] # Re: Traduction

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

        C'est dingue de voir qu'au bout de plus d'un an et demi on en parle encore, alors que son adversaire en a aussi dit de belles...

        Il serait temps de passer à autre chose !
  • # Pseudo dans les dépêches

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

    Ave,

    Pour une dépêche de cette importance, je préfère utiliser les noms que les pseudos que je réserverai aux journaux. Donc merci Victor STINNER pour ton journal et ton avis avisé :)

    Étienne.
  • # Tout les bugs ? vraiment ?

    Posté par . Évalué à 4.

    Personnellement je ne sais toujours pas comment acceder proprement à sys.argv et os.environ lorsque le contenu est arbitraire, par exemple pour que `find -print0 | xargs -0 monscript.py` marche avec des fichiers qui sont mal encodé.
    • [^] # Re: Tout les bugs ? vraiment ?

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

      Apparemment tu n'as pas trop pris le temps de chercher.

      Il suffit d'utiliser le module fileinput [http://docs.python.org/3.0/library/fileinput.html] que l'on trouve dans la documentation de sys.argv [http://docs.python.org/3.0/library/sys.html?highlight=filein(...)].
      La méthode fileinput.input [http://docs.python.org/3.0/library/fileinput.html#fileinput.(...)] permet d'ouvrir un flux (par défault le flux d'arguments) suivant un mode spécifié.
      With mode you can specify which file mode will be passed to open(). It must be one of 'r', 'rU', 'U' and 'rb'.

      La documentation de open [http://docs.python.org/3.0/library/functions.html#open] nous indique alors comment l'on configure l'ouverture d'un flux :

      ========= ===============================================================
      Character Meaning
      --------- ---------------------------------------------------------------
      ``'r'`` open for reading (default)
      ``'w'`` open for writing, truncating the file first
      ``'a'`` open for writing, appending to the end of the file if it exists
      ``'b'`` binary mode
      ``'t'`` text mode (default)
      ``'+'`` open a disk file for updating (reading and writing)
      ``'U'`` universal newline mode (for backwards compatibility; unneeded
      for new code)
      ========= ===============================================================


      Tu doit pouvoir alors convertir un flux de donné suivant un encodage spécifié (en l'occurrence celui du système).

      PS: je n'ai pas fait de python depuis 1 ans
      PS2: la documentation de python 3 est vraiment superbe
      • [^] # Re: Tout les bugs ? vraiment ?

        Posté par . Évalué à 4.

        Non c'est un vrai problème (qui est en discussion sur python-devel et qui selon moi est fondamental).


        $ ./python `printf '\xff'`
        Could not convert argument 1 to string

        tonfa@pirzuine:/tmp/Python-3.0$ PATH=`printf '\xff'`:$PATH ./python
        Python 3.0 (r30:67503, Dec 6 2008, 11:42:46)
        [GCC 4.3.2] on linux2
        Type "help", "copyright", "credits" or "license" for more information.
        >>> import os
        >>> os.environ['PATH']
        Traceback (most recent call last):
        File "", line 1, in
        File "/tmp/Python-3.0/Lib/os.py", line 389, in __getitem__
        return self.data[self.keymap(key)]
        KeyError: 'PATH'


        On ne peut pas passer des arguments, et les variables d'environnement qui ne peuvent pas être décodées sont virées.

        Dans le cas au dessus, l'unicode est mal encodé mais les mêmes problèmes arrivent si tu lance ton programme avec LANG=C. Dans ce cas les arguments unicodes ne peuvent être lus, et si une variable d'environnement contient de l'unicode elle est supprimée.
        • [^] # Re: Tout les bugs ? vraiment ?

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

          Non c'est un vrai problème (qui est en discussion sur python-devel et qui selon moi est fondamental).

          Effectivement, ce point épineux a provoqué des discussions assez houleuses sur la liste de diffusion. Il y a trois choses : sys.argv, noms des fichiers, et les variables d'environnement. Pour l'instant, tout est accessible en Unicode.

          Pour les fichiers, j'ai écrit un patch pour pouvoir utiliser des noms de fichier sous forme d'octets. Ce travail a pris plusieurs mois mais a été intégré pour la sortie de la version 3.0 finale.

          Pour les variables d'environnement (comme PATH), c'est en cours de discussion. Je pense que la version 3.1 pourra accéder aux variables d'environnement en tant qu'octets. Pour sys.argv, personne ne s'en est plaint (pas de bug ouvert, je crois) :-) Sûrement qu'à terme, il existera aussi une méthode pour accéder à la version en octets.

          La solution que je déteste et que plusieurs personnes essayent à chaque fois de pousser, est de stocker des octets dans Unicode en utilisant un encodage spécial (ex: utiliser une plage réservée d'Unicode). Mais je ne comprend pas l'intérêt car on revient au status pourri de Python2 qui mélange octets et caractères, source de nombreux bugs. En particulier, le texte Unicode n'est plus interopérable :-/

          À long terme, tous les systèmes utiliseront Unicode. Pour information, Windows utilise UTF-16 partout depuis très longtemps (Windows 98 je crois). Le problème est lorsqu'on mélange de vieilles partitions encodés avec des encodages différents. Il vaut mieux tout mettre en UTF-8 pour des raisons de simplicité. Python3 fait un pari sur l'avenir.

          Note : Sur un système sain (UTF-8 partout), Python3 fonctionne à merveille ! C'est très agréable d'avoir de l'Unicode partout !
          • [^] # Unicode et OS

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

            Pour information, Windows utilise UTF-16 partout depuis très longtemps (Windows 98 je crois)

            Ca, je veux voir ;-).
            Le moteur de Win9X (95, 98, Millenium) est en char uniquement (il y a un patch officiel pour le support d'UTF-16 toutefois, les applis Unicode peuvent alors communiquer avec Win9X en Unicode par le biais de cette couche qui fait la traduction, ça ralenti un peu mais ça va)
            C'est à partir de Windows NT 4 que Microsoft est passé en UCS-2 (pas UTF-16) puis les versions 5.x (2006, XP pour les noms commerciaux) en UTF-16.

            Note : Sur un système sain (UTF-8 partout), Python3 fonctionne à merveille ! C'est très agréable d'avoir de l'Unicode partout !

            Ca, c'est clair, moi qui travaille avec une tonne de langues, sans Unicode ça serait horrible (déjà que le "legacy" est pas triste...).
            Reste que le format d'enregistrement (UTF-8 dans un terminal et pour certaines API graphiques, UCS-4 pour d'autres API graphique, UCS-2/UTF-16 pour Windows) fait qu'on a quand même rajouté des trucs galères.
            Moi-même hésite toujours dans mes programmes entre UCS-x et UTF-8, chacun ayant des avantages et inconvénients, malheureusement.
          • [^] # Re: Tout les bugs ? vraiment ?

            Posté par . Évalué à 2.

            À long terme, tous les systèmes utiliseront Unicode. Pour information, Windows utilise UTF-16 partout depuis très longtemps (Windows 98 je crois). Le problème est lorsqu'on mélange de vieilles partitions encodés avec des encodages différents. Il vaut mieux tout mettre en UTF-8 pour des raisons de simplicité. Python3 fait un pari sur l'avenir.

            À mon avis on en est très loin, les kernel hackers sont loin d'être convaincu par cette approche qui s'éloigne de la vision unix du FS (les noms de fichiers sont des bytes, seul '\0' et '/' sont interdits).
            • [^] # Re: Tout les bugs ? vraiment ?

              Posté par . Évalué à 5.

              À mon avis on en est très loin, les kernel hackers sont loin d'être convaincu par cette approche qui s'éloigne de la vision unix du FS (les noms de fichiers sont des bytes, seul '\0' et '/' sont interdits).

              Ce n'est pas forcément un problème, cela délègue juste la décision au niveau de l'userspace pour ce qui est de la façon d'interpréter les octets en question.
              Bon, côté userspace on a les libc hackers et je ne suis pas sûr qu'ils soient plus compréhensifs :-)
  • # Super

    Posté par . Évalué à 2.

    Il ne manque plus que la sortie de Perl6 et PHP6.
    • [^] # Re: Super

      Posté par . Évalué à 8.

      Et e17, et Hurd....

      ---> [ ]
  • # CLI et boîtes de dialogue

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

    Il y a un remplaçant équivalent à Zenity, dont le paquet n'est plus maintenu ?

    Le genre de bibliothèque donnant la possibilité de faire afficher des boîtes de dialogue, confirmation, de choix, etc. sans devoir monter d'interface graphique.
    • [^] # Re: CLI et boîtes de dialogue

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

      Pour l'instant, Python3 intègre toute la bibliothèque standard (moins les vieux modules supprimés). Les modules tiers vont migrer petit à petit. Pour certain (comme PyQt), ça risque de prendre beaucoup de temps car l'API C (certains modules Python sont écrits en C) a beaucoup changé.

      Pour les modules écrit en pur Python, je trouve que la conversion est triviale ! L'outil 2to3 fait 90 à 100% du boulot. J'ai migré python-ptrace et Fusil (25.000 lignes de Python) en une après-midi.
      • [^] # Re: CLI et boîtes de dialogue

        Posté par . Évalué à 2.

        On peut aussi rajouter numpy et scipy qui vont etre galere a porter probablement. Deja que numpy ne fonctionne pas avec la version 2.6, c'est en cours de resolution, alors la version 3 c'est pas gagne.
  • # Nouveautés

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

    Petit rappel : Python 3.0 est basé sur Python 2.6. Donc entre 2.5 et 3.0, il y a toutes les nouveautés de Python 2.6 dont la liste est très longue ! Relire la dépêche Python 2.6 pour la peine :
    http://linuxfr.org/2008/10/02/24556.html

    En plus de ça, je trouve que la liste des nouveautés 3.0 donnerait presque envie de faire une croix sur Python2 ! Je pense par exemple à l'annotation des fonctions ou aux arguments sous forme de mot-clé uniquement (« def pouet(*, cle=42): ... »). Il y a aussi la syntaxe {1, 2, 3} pour les ensembles (set), les « compréhensions de dictionnaires », etc.
    • [^] # Re: Nouveautés

      Posté par . Évalué à 2.

      comme dit precedemment cela a l'air tres interessant la version 3 mais sans les extensions portes dessus cela n'interessera que peu de monde et pour le moment dans les extensions majeurs (enfin ce dont moi je me sers) il n'y en a aucune qui fonctionne sur la version 2.6 alors la version 3 il faut meme pas rever. Je parle de truc courrant tel que numpy, scipy, matplotlib, pil, pyqt4 et j'en oublie.
      • [^] # Re: Nouveautés

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

        Effectivement, l'adoption de la version 3 en production demandera probablement du temps pour ceux qui ont besoin des extensions développées en C/C++/Fortran.

        PIL 1.1.6 fonctionne avec Python 2.6, même un paquet précompilé pour win existe : http://www.pythonware.com/products/pil/

        Numpy : pas de paquet précompilé, cependant sous Linux je compile sans soucis l'extension qui a l'air de bien fonctionner pour mon utilisation

        Scipy, pyQt4 : non testés

        Quand à l'utilisation de ces extensions avec Python 3, laissons un peu de temps aux développeurs pour absorber les changements et nouveautés. Rien n'empêche de contribuer aussi rapports de bugs, corrections, etc ...

        Pour les impatients, compiler l'interpréteur et les extensions nécessaires en attendant les paquets "tout prêts" ;)
  • # C'est l'histoire ...

    Posté par . Évalué à 1.

    D'un mec sous windows qui voulais lancer une application python

    Il télécharga donc la dernière version, mais, malheur ! Cela ne marchait pas. Python renvoyait une erreur de syntaxe sur une bête ligne avec un print ...

    C'est vrai qu'en allant sur le site et en cherchant ''téléchargement'', c'est très facile de prendre la version 3.0. Le texte il commence par parler de programmation, donc le mec qui veut que un interpréteur, il zappe...

    Au final, il à posé des questions au développeur qui lui a gentiment indiqué que ses scripts ne marchent pas encore sur 3.0 ...


    C'est dommage qu'il n'ai pas été prévu de bien distinguer un source 2.X d'un source 3.0 et c'est dommage...
    • [^] # Re: C'est l'histoire ...

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

      Modulo quelques adaptations, il est possible d'écrire du code qui fonctione sur Python 1.5 .. 3.0. Exemple trivial : « print("Hello World!") ».
    • [^] # Re: C'est l'histoire ...

      Posté par . Évalué à 2.

      En général, le mec sous Windows il utilise la version py2exe-ifiée de son application Python, et tout va bien.
      • [^] # Re: C'est l'histoire ...

        Posté par . Évalué à 1.

        Ça c'est quand il cherche à lancer une application prévu pour Windows sous Windows.

        Mais personne ne va s'amuser à utiliser py2exe avec un script à la con de 100 lignes qui sert à générer des headers C ou à faire d'autres trucs obscurs dans le but de compiler.
  • # Unicode partout

    Posté par . Évalué à 2.

    L'unicode à tous les étages, ça va apporter des belles possibilités d'obfuscation.

    Je vois d'ici le potentiel fabuleux de la variable «   » (facilement accessible en bépo sur shift-espace).
  • # Trollons peu trollons bien

    Posté par . Évalué à 3.

    On a des benchmarks comparatif ? :)
    • [^] # Re: Trollons peu trollons bien

      Posté par . Évalué à 3.

      Alors super, en effet, j'en ai fait un rapide maison pour comparer les deux interpréteurs :
      La ligne de commande :
      i=1 ; while [ "${i}" -ne "10" ] ; do echo $i ; python script_test_python_3.py ; python3 script_test_python_3.py ; i=$[${i}+1] ; done
      Le code du script :

      import time
      a=time.time()
      b=range(0,100)
      c=[k**2 for k in b]
      final = time.time() - a
      print(final)

      Les résultats (python 2.6 est en premier) :
      1
      0.000126838684082
      0.000236034393311
      2
      0.000123023986816
      0.000237226486206
      3
      0.000124931335449
      0.000236988067627
      4
      0.000123977661133
      0.000236034393311
      5
      0.000126123428345
      0.000237941741943
      6
      0.000127077102661
      0.000236988067627
      7
      0.000124931335449
      0.000236988067627
      8
      0.000123977661133
      0.000236988067627
      9
      0.000125885009766
      0.000236034393311

      Les deux version packagées dans ma distribution :
      Python 3000 :

      Nom : python3
      Version : 3.0-3
      URL : http://www.python.org
      Licences : custom
      Groupes : --
      Fournit : --
      Dépend de : bzip2 gdbm openssl>=0.9.8i zlib
      Dépendances opt. : tk: for IDLE, pynche and modulator
      Requis par : --
      Incompatible avec : --
      Remplace : --
      Taille (installé) : 60488,00 K
      Paqueteur : Allan McRae <allan@archlinux.org>
      Architecture : i686
      Compilé le : dim. 07 déc. 2008 05:55:39 CET
      Installé le : dim. 07 déc. 2008 14:04:00 CET
      Motif d'installation : Explicitement installé
      Script d'installation : Non
      Description : Next generation of the python high-level scripting language

      Python 2.6 :
      Nom : python
      Version : 2.6-2
      URL : http://www.python.org
      Licences : custom
      Groupes : --
      Fournit : python-elementtree python-ctypes
      Dépend de : db bzip2 gdbm openssl>=0.9.8d zlib
      Dépendances opt. : tk: for IDLE, pynche and modulator
      Requis par : boost gvim libieee1284 menumaker mercurial openoffice-base pil pycairo pygobject python-nose python-numeric vim
      Incompatible avec : --
      Remplace : python-elementtree python-ctypes
      Taille (installé) : 62468,00 K
      Paqueteur : Allan McRae <allan@archlinux.org>
      Architecture : i686
      Compilé le : lun. 27 oct. 2008 11:52:15 CET
      Installé le : jeu. 06 nov. 2008 15:46:31 CET
      Motif d'installation : Explicitement installé
      Script d'installation : Non
      Description : A high-level scripting language

      Donc, je ne sais pas si c'est une bonne idée d'utiliser python 3 puisque le temps de calcul passe alors du simple au (quasi) double.

      C'est grave non ? Et Guido van Rossum qui se plaignait que les autres langages de scripts devenaient des vraies poubelles et gagnait en lourdeur au fil de leur évolution ? Que se passe-t-il donc dans python 3 ?
      • [^] # Re: Trollons peu trollons bien

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

        Pour faire un test de performance, il serait probablement judicieux d'avoir l'interpréteur compilé avec les mêmes options et dans les mêmes conditions. Voici mon petit test.

        Kernel 2.6.18-6-k7
        CPU : Athlon 1.2 GHz (*)
        RAM : 512 Mo DDR

        Python 2.6.1 et 3.0 compilés avec les options suivantes :
        ./configure --with-fpectl --with-wctype-functions --with-pymalloc --with-doc-strings --with-threads --with-signal-module --with-system-ffi --enable-ipv6

        Compilateur (affiché dans la console interpréteur) :
        [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)]

        Ensuite j'ai repris le test précédent, dont voici les résultats obtenus :

        10 itérations : (moyennne, écart-type)
        python 2.6.1 = ( 0.00012204382154655558 ; 4.133267903850333e-06 )
        python 3.0 = ( 0.0001832379235161111 ; 1.0711521205702668e-05 )

        10 échantillons c'est un peu faible, la tendance qui se dégage est que Python 3 est plus lent *sur ce test*, dans des conditions égales de compilation et d'exécution. Bien évidemment pour être affirmatif, il est nécessaire d'effectuer des tests de performances mettant en oeuvre des algorithmes choisis avec un nombre suffisamment grand d'échantillons.

        Pour conclure, personellement, si j'ai besoin de performance de calcul je préfère de loin utiliser un algo en C ou Fortran que j'appelle dans l'interpréteur, c'est tellement simple et confortable.

        [HS]
        (*) Certains vont rire car parler de "performances" avec une telle machine face à celles d'aujourd'hui peut sembler incongru. Cependant elle n'a rien a envier aux netbooks à la mode et ronronne comme un chat depuis plus de 7 ans. (parfois le chat est enroué, saleté de poussière qui désaxe les ventilos !)
        [/HS]
        • [^] # Re: Trollons peu trollons bien

          Posté par . Évalué à 1.


          Pour conclure, personellement, si j'ai besoin de performance de calcul je préfère de loin utiliser un algo en C ou Fortran que j'appelle dans l'interpréteur, c'est tellement simple et confortable.

          Oui, dans ce cas, ça pose la question de savoir pour quel domaine d'utilisation python est-il conçu. Étant un langage interprété, est-ce que la performance peut être sacrifiée sur l'autel de la souplesse de développement et d'exécution ?

          Est-ce que la performance est un problème pour l'utilisation de Python ? À vrai dire, je me pose la question de savoir dans quel cas la performance est un problème critique. Il est vrai que j'aimerai parfois que Python soit ultra rapide, mais c'est vrai qu'un calcul peut être à même d'être plus rapidement réalisé avec le C qu'avec Python.

          Je voudrai noter cependant que, ayant consulté le livre de référence de Python (Python en concentré), il suggère d'utiliser les modules issus de la bibliothèque gmp pour les calculs numériques. Enfin à vous de voir.
      • [^] # Re: Trollons peu trollons bien

        Posté par . Évalué à 2.

        C'est grave non ?

        En fait non. Si tu as vraiment besoin de calculs très rapides sur de grosses quantités de données, tu fais des sous-routines en C.

        Python 3.0 est plus lent sur trois points :
        - le calcul de petits entiers car tous les entiers sont maintenant de précision arbitraire ("infinie" si ce n'est bien sûr la mémoire virtuelle disponible pour le processus)
        - les chaînes de caractères qui sont désormais unicode par défaut (avec une occupation mémoire doublée et donc une moins grande efficacité des caches)
        - la couche IO qui a été réécrite, et pour l'instant en majorité en Python plutôt qu'en C

        Les deux premiers points ne sont pas cruciaux, car les pertes ne sont pas énormes comparées au coût d'interprétation qui lui n'a pas vraiment changé. Le troisième point devra être corrigé dans Python 3.1.

        Il y a des comparaisons de performance entre Python 2.5 / 2.6 / 3.0 ici (mais attention, versions beta, pas versions finales, il y a eu quelques corrections entre temps) :
        http://mail.python.org/pipermail/python-dev/2008-August/0819(...)

        Et Guido van Rossum qui se plaignait que les autres langages de scripts devenaient des vraies poubelles et gagnait en lourdeur au fil de leur évolution ?

        Je ne sais pas à quoi tu fais allusion mais il parlait certainement de l'accumulation de bricolages syntaxico-sémantiques qui mène à ce à quoi ressemblent Perl ou Javascript aujourd'hui. De ce côté-là Python 3 est effectivement une simplification.
        • [^] # Re: Trollons peu trollons bien

          Posté par . Évalué à 2.

          >> les chaînes de caractères qui sont désormais unicode par défaut (avec une occupation mémoire doublée et donc une moins grande efficacité des caches)<<

          Quel encodage utilise Python?
          Parce que si c'est UTF-8, il n'utilisera pas plus de place pour les chaines ASCII qu'ASCII justement..
          • [^] # Re: Trollons peu trollons bien

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

            Quel encodage utilise Python?

            De ce que j'ai compris, c'est un "vrai" support d'Unicode (sinon aucun intérêt d'en parler, on peut toujours faire de l'UTF-8 avec des vieux softs, le problème d'UTF-8 étant pour les découpages/comptage), donc ça va doubler voir quadrupler (le post initial parle de doubler, donc UTF-16 comme pour Java? Pas UCS-4 comme sous Linux?)

            Parce que si c'est UTF-8, il n'utilisera pas plus de place pour les chaines ASCII qu'ASCII justement..

            Oui, mais bon, la on est sur un site français, pas américain, donc l'ASCII est un peu limité pour nous. D'ailleurs, "limité" ne fait pas 6 octets en UTF-8... Donc pour notre langue, UTF-8 utilisera plus de place que le latin-1 habituel.
            • [^] # Re: Trollons peu trollons bien

              Posté par . Évalué à 3.

              (le post initial parle de doubler, donc UTF-16 comme pour Java? Pas UCS-4 comme sous Linux?)

              C'est une option à la compilation de Python. Les binaires officiels Windows sont compilés en UTF-16 (parce que ça rend la communication avec les API Windows plus efficace), quant aux version Linux ça dépend de la politique de la distribution (Debian compile en UTF-32, Mandriva en UTF-16).
            • [^] # Re: Trollons peu trollons bien

              Posté par . Évalué à 1.

              ??
              J'aimerai bien savoir en quoi UTF-8 n'est pas un vrai support d'Unicode..

              La réponse du dessous que c'est une option a la compilation parait plus logique, donc cela veut dire que l'utilisation mémoire sera soit grosso-modo inchangée par rapport a latin-1/ASCII (bin oui, compté le nombre d'accent utilisé en moyenne dans une phrase..) soit doublée (UTF-16) soit quadruplée (UTF-32).

              Je comprends qu'on utilise UTF-16 sous Windows l'OS utilisant UTF-16, par contre sous Linux utiliser UTF-16 ou UTF-32 j'ai plus de mal a comprendre: les CPUs sont tres puissant donc "gacher" de la mémoire/du cache, cela ne me parait pas optimal..
              • [^] # Re: Trollons peu trollons bien

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

                J'aimerai bien savoir en quoi UTF-8 n'est pas un vrai support d'Unicode..

                Avec UTF-8, tu as plein de merdes : tu coupes là ou il ne faut pas et hop tu as des octets invalides, ça rame pour compter (strlen() comptent le nombre d'octets, pas le nombres de caractères) etc.
                (c'est le même problème dans 0.001% des cas avec Windows toutefois, car c'est que UTF-16, les plages >0x7FFF étant sur 2 fois 2 octets).

                Bref, pour le traitement de caractères, UTF-16/32 a plein d'avantages (perf etc...)

                par contre sous Linux utiliser UTF-16 ou UTF-32 j'ai plus de mal a comprendre:

                * Java utilise UTF-16 (ou UCS-2 je ne sais plus), donc pour un binding c'est mieux
                * UCS-4 /UTF-32 est la norme habituelle de Linux pour Unicode. J'avoue avoir du mal à comprendre le choix d'UTF-16 pour les compilations Linux du coup.

                cela ne me parait pas optimal.

                UTF-16/32 est loin d'être optimal aussi pour certaines choses. Il y a des avantages et des inconvénients que ce soit UTF-8 ou UCS-4, faut choisir entre les inconvénients. Le choix est loin d'être simple.
                En C/C++, du coup on laisse le choix au programmeur plutôt que de lui forcer la main.
                • [^] # Re: Trollons peu trollons bien

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

                  Python utilise UCS-2 ou UCS-4 en interne (selon des options de compilation). Cet encodage garantit un temps d'accès en O(1) à un caractère selon sa position, contrairement à UTF-* qui ont des temps d'accès en O(n). Pour les expressions régulières par exemple, je pense que ça accélère beaucoup :-) Pour UCS-2, si un essaye de créer un caractère hors de [0; 65535], une exception est lancée.
                  • [^] # Re: Trollons peu trollons bien

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

                    Pour UCS-2, si un essaye de créer un caractère hors de [0; 65535], une exception est lancée.

                    Ca, c'est sympa pour les codes >0xFFFF sous Windows et Mandriva... Bon, ca concerne 0.01% de la planète, mais ça va leur faire mal niveau "on accepte tout le monde" (bon, honnêtement, j'en ai vu des caractère bizarres, mais pas encore ce genre de caractères...)
                    Mais pourquoi diable Mandriva a compilé en UCS-2 si j'en croit le post au dessus?
                  • [^] # Re: Trollons peu trollons bien

                    Posté par . Évalué à 5.

                    Pour UCS-2, si un essaye de créer un caractère hors de [0; 65535], une exception est lancée.

                    Non, Python 3 décompose le caractère en deux codes :

                    Python 3.1a0 (py3k, Dec 7 2008, 21:13:32)
                    [GCC 4.3.2] on linux2
                    Type "help", "copyright", "credits" or "license" for more information.
                    >>> import sys
                    >>> sys.maxunicode
                    65535
                    >>> s = chr(0x10000)
                    >>> len(s)
                    2
                    >>> s
                    '\U00010000'
                    >>> s.encode('utf-32le')
                    b'\x00\x00\x01\x00'

                    (sous un build UCS-4, len(s) retournerait 1)
        • [^] # Re: Trollons peu trollons bien

          Posté par . Évalué à 2.

          Je ne sais pas à quoi tu fais allusion mais il parlait certainement de l'accumulation de bricolages syntaxico-sémantiques qui mène à ce à quoi ressemblent Perl ou Javascript aujourd'hui. De ce côté-là Python 3 est effectivement une simplification.

          Tu fais référence à tous les nouveaux mot-clefs (as, with, mais aussi True et False...) ?
          • [^] # Re: Trollons peu trollons bien

            Posté par . Évalué à 3.

            Bah, un mot clé n'est pas redondant par définition. Certaines choses sont redondantes, par exemple la définition fonctionnelle :
            [ i**2 for i in range(0,100) ]
            et les fonctions map() et filter() qui sont issues des langages fonctionnels. C'est typiquement une redondance du langage, ce qui est à l'opposé de ce qu'a souhaité le concepteur.

            C'est une philosophie à l'opposé du langage Perl, où il y a toujours plusieurs possibilités pour faire une chose précise.
          • [^] # Re: Trollons peu trollons bien

            Posté par . Évalué à 3.

            Tu fais référence à tous les nouveaux mot-clefs (as, with, mais aussi True et False...) ?

            Ils ne sont pas nouveaux, c'est juste qu'avant ce n'étaient pas des mots réservés (on pouvait appeler une variable "as" ou "True" par exemple). En d'autres termes, le langage n'est pas devenu plus complexe de ce côté-là, mais il y a eu quelques ajustements dans l'implémentation.

Suivre le flux des commentaires

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