samedi 15 novembre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Articles

Liens connexes

Python (350 hits)
What’s New in Python 2.6 (538 hits)
Propositions d'améliorations de Python (PEP) (147 hits)
Générateur de documentation Sphinx (308 hits)
Python sur dmoz (338 hits)

Dépêche modérée par

rootix

Dépêche éditée par

Articles : Nouvelle version majeure de Python (2.6)

Posté par Victor STINNER (page perso, ). Modéré le 02 octobre 2008.

En attendant la sortie de Python3 prévue mi-octobre, le langage de programmation Python sort en version 2.6. Cette version vise à préparer la migration vers Python3 et apporte énormément de nouveautés, aussi bien dans le langage que dans la bibliothèque standard. Les principales nouveautés sont décrites dans la seconde partie de cet article.

Le développement de Python est ouvert et suit les propositions d'améliorations (PEP). L'outil de suivi de bugs (bugs.python.org) a migré de Sourceforge à une installation personnalisée de Roundup. La documentation LaTeX a été convertie dans le format reStructuredText et est maintenant compilée avec l'outil Sphinx, développé pour l'occasion.

Python (350 hits)
What’s New in Python 2.6 (538 hits)
Propositions d'améliorations de Python (PEP) (147 hits)
Générateur de documentation Sphinx (308 hits)
Python sur dmoz (338 hits)

> Lire la suite (47 commentaires, moyenne: 2,6). [dépêche : 5340 caractères]

Améliorations du langage

La PEP 3101 (Advanced String Formatting) révolutionne la manière de formater une chaîne de caractères. Exemples : "{0} {1}!".format("Hello", "World") ou "objet={obj}, taille={obj.taille}".format(obj=mon_objet). On peut réutiliser un argument plusieurs fois, changer l'ordre des arguments, lire un attribut d'un objet, lire un valeur dans un dictionnaire, etc.
La PEP 3119 (Introducing Abstract Base Classes) permet de spécifier qu'une classe implémente une interface. Exemples d'ABC : Hashable, Iterator, Sized. Voir aussi la PEP 3141 (A Type Hierarchy for Numbers).
Grâce à la PEP 3129 (Class Decorators), les décorateurs sont maintenant applicables aux classes.
L'usage de with se généralise et est simplifié par la création du module contextmanager.

Nouveaux modules et nouvelles classes

Le module multiprocessing est une réponse à la parallélisation massive des ordinateurs (processeurs multi-cœurs). Il permet d'exécuter une fonction dans plusieurs processus séparés de manière transparente. Rappel : à cause du Global Interpreter Lock (GIL), Python est incapable d'exécuter plusieurs threads en parallèle.
Le module json gère la sérialisation d'objets dans le format JavaScript Object Notation (supporte l'import et l'export).
Le module fractions contient la classe Fraction qui stocke la valeur exacte d'une fraction que les nombres flottants ne peuvent qu'approximer. D'ailleurs, le type float() supporte maintenant les valeurs « nan » (not an number), « +inf » et « -inf ».

Compatibilité avec Python3

Nombreuses fonctionnalités Python3 sont accessibles de manière optionnelles, par exemple par le module future_builtins :

Avec « from __future__ import print_function », on peut utiliser print comme une simple fonction, alors que par défaut c'est un mot clé dans Python2. Exemple : print("Hello", "World", sep="_", end="!\n", file=sys.stdout) affiche « Hello_World! ». Lire la PEP 3105 (Make print a function).
Les nombres peuvent être écrits directement en binaire. Le nouveau préfixe octal est « 0o ». Exemples : deux = 0b10 et dix=0o10. Lire la PEP 3127 (Integer Literal Support and Syntax).
La PEP 3110 (Catching Exceptions in Python 3000) introduit une notation alternative pour les exceptions : « except (ValueError, TypeError) as err: ». Elle évite les erreurs du type « except ValueError, TypeError: ».
Création du type bytes() qui est en fait un alias de str(). La PEP 3112 (Bytes literals in Python 3000) introduit les chaînes d'octets littérales : b'octets' est équivalent à 'octets'. Sauf avec « from __future__ import unicode_literals », dans quel cas les chaînes seront considérées de type unicode : 'unicode' vs b'octets').
La PEP 3116 (New I/O) décrit le module io, la nouvelle bibliothèque d'entrée/sortie. Par défaut, c'est l'ancienne bibliothèque qui est utilisée. Utilisez par exemple io.open() pour accéder à vos fichiers textes en unicode.

Interprète Python

Un utilisateur peut installer des modules Python dans son dossier personnel. Exemple : dossier « ~/.local/lib/python2.6/site-packages » dans le cas de Linux.
Il est désormais possible de contrôler l'écriture des scripts Python compilés (.pyc et .pyo) avec l'option -B de Python et la variable d'environnement PYTHONDONTWRITEBYTECODE.

Faut-il migrer à Python3 ?

Python2 n'est pas près d'être remplacé par Python3. La migration se fera en douceur et progressivement.

Pour l'instant, il est recommandé d'écrire du code Python2 et le convertir avec l'outil 2to3 (intégré dans Python 2.6). En cas de problème, corriger le code original en évitant, dans la mesure du possible, d'introduire des tests sur le numéro de version.

Sachant que des projets ont mis plusieurs mois à migrer de Python 2.4 à Python 2.5, il y a peu de chance pour que les projets majeurs migrent complètement à Python3.

Python 2.7 est déjà prévu et améliorera encore la compatibilité entre Python2 et Python3. En attendant, Python 3.0 nous réserve encore quelques surprises (comme les arguments sous forme de mot clé uniquement, oups, ce n'est plus une surprise) !

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

dix???

Posté par case42 (page perso, ) le 02/10/2008 à 10:32. (lien). Évalué à 9.

Le nouveau préfixe octal est « 0o ». Exemples : deux = 0b10 et dix=0o10

heu... c'est pas plutôt huit=0o10 , ou j'ai rien compris?

[^]Re: dix???

Posté par baud123 (Jabber id, page perso, ) le 02/10/2008 à 10:47. (lien). Évalué à 3.
c'est huit(base 10) = 0o10 (base octale)

[^]Re: dix???

Posté par furai (page perso, ) le 02/10/2008 à 11:47. (lien). Évalué à 4.
ça ne reste jamais que le nom d'une variable...
- [^]Re: dix???
  
  Posté par Édouard SIHA-ARCELUZ (page perso, ) le 02/10/2008 à 15:53. (lien). Évalué à 5.
  Sauf qu'une variable intelligemment nommée décrit ce qu'elle contient.

[^]Re: dix???

Posté par Archibald (page perso, ) le 02/10/2008 à 17:47. (lien). Évalué à 2.
Peu importe puisque c'est correct en base 42 (si, si !).

[^]Re: dix???

Posté par donkee () le 03/10/2008 à 09:07. (lien). Évalué à 1.
Effectivement si le nom de la variable indique ce quelle contient, on devrait lire:
dix=0o12
- [^]Re: dix???
  
  Posté par freeze () le 03/10/2008 à 22:47. (lien). Évalué à 2.
  et la renommer quand on l'incrémente ? pfiou ça va devenir chaud de faire du code lisible ;)

GIL

Posté par jideel () le 02/10/2008 à 11:19. (lien). Évalué à 2.

Vu sur http://docs.python.org/dev/library/multiprocessing.html :

multiprocessing is a package that supports spawning processes using an API similar to the threading module. The multiprocessing package offers both local and remote concurrency, effectively side-stepping the Global Interpreter Lock by using subprocesses instead of threads. Due to this, the multiprocessing module allows the programmer to fully leverage multiple processors on a given machine. It runs on both Unix and Windows.

[^]Re: GIL

Posté par Larry Cow () le 02/10/2008 à 11:35. (lien). Évalué à 4.
Euh, oui, et? C'est exactement ce que disait Victor, non? Le nouveau module permet d'utiliser efficacement les multi-coeurs en s'appuyant sur des processus distincts, puisqu'avec des threads ça ne peut pas marcher à cause du GIL.

Ou bien j'ai raté un truc?
- [^]Re: GIL
  
  Posté par baud123 (Jabber id, page perso, ) le 02/10/2008 à 11:38. (lien). Évalué à 3.
  Ou bien j'ai raté un truc ?
  
  croire que tout le monde RTFA* ? :D
  
  * en:RTFA tout en bas
- [^]Re: GIL
  
  Posté par karteum59 () le 02/10/2008 à 11:49. (lien). Évalué à 1.
  A ce sujet, j'ai découvert Stackless Python il y a peu (http://www.stackless.com/ )
  Est-ce que qqun sait s'il y a une coopération avec le Python legacy ?
  - [^]Re: GIL
    
    Posté par Antoine () le 02/10/2008 à 14:08. (lien). Évalué à 1.
    Stackless Python est une modification assez extensive de l'interpréteur standard. Il n'y a pas de coopération entre les deux équipes (celle de Stackless étant à mon avis très réduite), mais le fait que Stackless soit dérivé de CPython implique qu'il n'y aura pas divergence, sauf sur les points qui précisément sont la raison d'être de Stackless.
    - [^]Re: GIL
      
      Posté par Antoine () le 02/10/2008 à 14:10. (lien). Évalué à 1.
      PS : un sous-ensemble des fonctions apportées par Stackless est fourni par l'extension "greenlets", qui est compatible avec l'interpréteur standard
      
      http://codespeak.net/py/dist/greenlet.html
  - [^]Re: GIL
    
    Posté par Victor STINNER (page perso, ) le 02/10/2008 à 14:42. (lien). Évalué à 4.
    Pour les alternatives aux threads, je te conseille de regarder du projet PyPy. Il a déjà intégré une partie de (ou tout ?) Stackless Python.

[^]Re: GIL

Posté par TImaniac (page perso, ) le 02/10/2008 à 15:43. (lien). Évalué à 2.
Pour utiliser les threads en Python... suffit d'utiliser IronPython \o/
http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPytho(...)

--
MonoFrance
- [^]Re: GIL
  
  Posté par Gniarf () le 02/10/2008 à 21:27. (lien). Évalué à 2.
  et .NET, donc poubelle.
  
  --
  Windows has no users. It has hostages.
  - [^]Re: GIL
    
    Posté par TImaniac (page perso, ) le 03/10/2008 à 13:29. (lien). Évalué à 3.
    pas besoin de .NET, juste d'une implémentation correcte de la CLI et du CLR, 2 standards définis par l'ECMA et l'ISO.
    
    --
    MonoFrance
    - [^]Re: GIL
      
      Posté par Gniarf () le 03/10/2008 à 15:01. (lien). Évalué à 7.
      oh oui alors hein, alors les standards de l'ECMA et de l'ISO, hein, depuis le gag du Microsoft Office Open XML, comment dire, je prends des gants, là.
      
      --
      Windows has no users. It has hostages.
      - [^]Re: GIL
        
        Posté par TImaniac (page perso, ) le 03/10/2008 à 22:05. (lien). Évalué à 2.
        Bah la FSF ne fait pas autant de manière que toi avec dotGNU. La limite entre "j'exprime ma parano" et "je FUD" est très floue.
        
        --
        MonoFrance
        
        [^]Re: GIL
        
        Posté par Gniarf () le 04/10/2008 à 01:40. (lien). Évalué à 2.
        > La limite entre "j'exprime ma parano" et "je FUD" est très floue.
        
        mh là c'est toi l'expert, je ne pratiquais ni l'un ni l'autre.
        
        --
        Windows has no users. It has hostages.
        
        [^]Re: GIL
        
        Posté par TImaniac (page perso, ) le 04/10/2008 à 16:15. (lien). Évalué à 2.
        L'ECMA garantie que les standards peuvent être implémentées par n'importe qui, il n'y a donc pas de frein à implémenter la CLI ou la CLR et donc à utiliser IronPython sans dépendre de .NET.
        Tu sous-entends le contraire en mettant en doute les qualités de ces organismes en comparant le processus de normalisation d'un autre format qui a attiré les foudres de nombreux linuxiens.
        Donc oui, soit t'es parano sur tout ce que normalise MS, soit tu cherches délibéremment à FUDer sans argumenter/détailler ta comparaison.
        
        --
        MonoFrance
        
        [^]Re: GIL
        
        Posté par Albert () le 04/10/2008 à 16:26. (lien). Évalué à 1.
        Ce qui est generalement mis en doute dans .NET c'est:
        
        1 - toute la partie non ouverte et couverte de brevet.
        2 - Recemment il y a eu une interview du responsable de C# et .NET et il disait que la prochaine version serait peut etre normalise.
        
        Et comme d'hab on va pas revenir sur le fait que l'implementation de mono a toujours une version de retard. Si l'on compare avec Java ou python c'est flagrant la difference de support sur les OS non microsoftiens... Mais c'est vrai c'est pas la faute de Microsoft ils ont que des incapables qui sont pas foutu de programmer sur un vrai OS (Je suis tres ironique naturellement et).
        
        [^]Re: GIL
        
        Posté par TImaniac (page perso, ) le 05/10/2008 à 14:46. (lien). Évalué à 3.
        Ce qui est generalement mis en doute dans .NET c'est
        Mon propos était justement de dire qu'IronPython ne dépendait pas de .NET. Enfin si un petit peu puisque son implémentation dépend de la partie DLR (Dynamic Language Runtime) non standardisé/normalisé... mais que Microsoft a mis sous licence libre.
        IronPython marche sous linux aujourd'hui, c'est une réalité, pas la peine de troller sur .NET, c'est pas le propos.
        
        --
        MonoFrance
        
        [^]Re: GIL
        
        Posté par Gniarf () le 06/10/2008 à 01:20. (lien). Évalué à 2.
        je ne vois pas le rapport entre "parano", "FUD" et ici douter d'organismes de normalisation qui viennent de prouver récemment qu'ils ne sont pas dignes de confiance, ou bien complètement manipulés. ce n'est pas une histoire de "linuxiens" du tout, ni même de Microsoft ici, ce sont des procédures de décision et de vote totalement baffouées, des évènements très mystérieux dans tout plein de pays, pour ne pas parler de corruption.
        
        donc bon ces organismes, niveau crédibilité, intégrité, tout ça, ça va plus.
        
        ensuite tu me dis que l'ECMA me garantit des trucs, des espèces de droits, que je pourrais implémenter ces standards sans soucis et je devrais leur faire confiance ?
        
        --
        Windows has no users. It has hostages.
        
        [^]Re: GIL
        
        Posté par TImaniac (page perso, ) le 06/10/2008 à 15:53. (lien). Évalué à 3.
        donc bon ces organismes, niveau crédibilité, intégrité, tout ça, ça va plus.
        Ok dérivons un peu.
        L'ISO a perdu de la crédibilité de ton point de vue (et sans doute du point de vue de nombreuses personnes, surtout côté libristes), mais globalement il répond toujours aux attentes de ceux qui l'utilisent : un moyen pour les industriels de mettre en avant une norme pour des raisons purement commerciales (l'interopérabilité peut être un besoin commercial), je sais pas ce que s'imaginaient les bisounours libristes et le pourquoi de l'ODF à l'ISO.
        Les votants "nationaux" ne sont là que pour protéger les intérêts de leurs industries respectives, d'où les "pressions" et autres "corruptions".
        Bref l'ISO continue son petit bonhomme de chemin malgré la polémique.
        
        Mais franchement dire que ce que garantie l'ECMA en terme de droits doit être mis en doute parcque l'ISO a normalisé un truc qui te plait pas, c'est du FUD pur et simple. Ou alors tu nous fait une belle démonstration argumentée qui prouve tes allégations (à savoir qu'on ne peut pas implémenter la CLR/CLI pour faire tourner IronPython).
        
        --
        MonoFrance
  - [^]Re: GIL
    
    Posté par Victor STINNER (page perso, ) le 06/10/2008 à 17:58. (lien). Évalué à 4.
    Quand j'écris une dépêche je lis toujours attentivement les commentaires pour y réagir. J'ai passé toute une nuit à écrire cette dépêche. Alors quand je vois vieux troll (Microsoft, ISO, ECMA, FUD, etc.) totalement dénué d'intérêt (c'est du déjà vu, revu et rerevu), je trouve ça vraiment minable.
    
    C'est une excellente chose qu'il existe différentes implémentations de Python. Si Microsoft (IronPython) ou Sun (Jython) sponsporise la sienne pour que Python s'intègre mieux à leurs environnement (resp. .NET et Java), je trouve ça bien. D'une manière ou d'une autre, ils contribuent à Python (ex: ça permet à plus de gens d'utiliser Python). Si la licence ne vous plait pas, passez-vous en ou recodez votre implémentation. Pour IronPython, je suppose que ça fonctionne sur Mono. Si ce n'est pas le cas, patchez Mono plutôt que de nous faire perdre du temps.
- [^]Re: GIL
  
  Posté par Victor STINNER (page perso, ) le 02/10/2008 à 22:08. (lien). Évalué à 3.
  IronPython n'utilise pas de GIL ? Si c'est vrai, c'est une excellente nouvelle. PyPy utilise encore le GIL. On voit là l'intérêt d'avoir plusieurs implémentations différentes de Python, chacune a ses qualités et ses défauts : CPython, IronPython, Jython, PyPy, etc. (tiens, et Python pour Parrot ça en est où ?)
  - [^]Re: GIL
    
    Posté par TImaniac (page perso, ) le 03/10/2008 à 13:33. (lien). Évalué à 2.
    IronPython n'utilise pas de GIL ? Si c'est vrai
    c'est même un des avantages avancés :
    http://wiki.python.org/moin/IronPython
    
    --
    MonoFrance
  - [^]Re: GIL
    
    Posté par Albert () le 03/10/2008 à 15:56. (lien). Évalué à 2.
    a propos de Jython, cela bouge aussi de ce cote la car une version 2.5alpha a vu le jour. Sachant que Jython stable en est encore a 2.2.
    
    http://www.jython.org/Project/
    - [^]Re: GIL
      
      Posté par TImaniac (page perso, ) le 03/10/2008 à 22:06. (lien). Évalué à 2.
      Jython qui lui non plus n'a pas le problème du GIL.
      
      --
      MonoFrance
      - [^]Re: GIL
        
        Posté par Albert () le 03/10/2008 à 23:30. (lien). Évalué à 2.
        Chose assez peu surprenant vu que ironpython et jython on le meme pere a la base.

2to3 … nostalgie … ou pas

Posté par Frédéric Heulin () le 02/10/2008 à 11:45. (lien). Évalué à 3.

From two to two to two two [http://www.paroles.net/chanson/15269.1] ... salut Boby :)

Je devrais aller prendre l'air moi je crois …

PS: Sinon pitié ramenez pas les 2be3 sous prétexte que ça ressemble plus hein.

[^]Re: 2to3 … nostalgie … ou pas

Posté par Johan Charpentier (Jabber id, ) le 03/10/2008 à 11:53. (lien). Évalué à 1.
Celui qui te les sortira pourra sortir en beauté :

~~~"Partir un jour, sans retour"~~~>[- ]

--
"We may not live to see yesterday". (Hoagie)

docs HS

Posté par Greg (page perso, ) le 02/10/2008 à 14:41. (lien). Évalué à 2.

Ce qui explique que la doc de python était innaccessible depuis ce matin ! Et là, elle vient de changer, c'est tout nouveau tout beau, juste un peu lent :o)

Content de retrouver la doc, je commençais à ramer :)

[^]Re: docs HS

Posté par Victor STINNER (page perso, ) le 02/10/2008 à 14:43. (lien). Évalué à 2.
Tu peux consulter la documentation en local en l'installant chez toi. Exemple pour Debian / Ubuntu : « apt-get install python2.5-doc ». Oui, il y a eu un petit clash pour la màj de la doc sur python.org. C'est corrigé maintenant.

python 3.0

Posté par ribwund () le 03/10/2008 à 13:12. (lien). Évalué à 2.

J'étais encore mitigé sur python 3.0, mais après avoir testé les bytes/string/unicode pour voir si c'était possible de porter mercurial, je suis relativement déçu.

En effet c'est un énorme merdier la gestion des noms de fichiers. Étant donné que sous linux c'est fondamentalement des bytes, pourtant la plupart des fonctions os renvoient des strings (donc unicode). En fait actuellement c'est encore plus le bordel vu que ça peut renvoyer un mélange de bytes et de str. Par contre sous windows c'est de l'unicode derriere.

Franchement je vois pas quelle solution peut marcher, pour mercurial on a besoin d'avoir des listes de fichiers de façon indépendante de l'OS et du charset, c'est pas trop possible...

Voir http://bugs.python.org/issue3187 pour le bugreport.

[^]Re: python 3.0

Posté par Victor STINNER (page perso, ) le 03/10/2008 à 14:07. (lien). Évalué à 4.
Je suis en partie à l'origine de ce merdier :-) J'ai écrit le document suivant pour faire l'état de Python3 :
http://wiki.python.org/moin/Python3UnicodeDecodeError

En gros :
- Sous Windows n'utilisez que des chaînes Unicode
- Sous Linux et BSD (Mac OS X est un BSD) utilisez de l'Unicode si vous êtes fainéants (et vous avez raison ! « Sois fainéant, sois fainéant, tu vivras longtemps ! » chantait Coluche). Si vous voulez vraiment gérer les cas de merde (fichiers encodés n'importe comment, machine mal configurée), utilisez le type bytes (et des fonctions comme os.getcwdb()).

Pour info, svn refuse les fichiers dont le nom est encodé n'importe comment :
$ svn stat
(rien)
$ touch $(echo -e "oups\xff")
$ svn stat
(hex: 6f 75 70 73)
suivies par une séquence UTF-8 invalide
(hex: ff)

J'ai écrit un patch pour Python3 qui a été appliqué hier qui permet d'utiliser des noms de fichier sous forme de chaînes d'octets.

Finalement, Python3 simplifie le bordel car il passe TOUT en unicode (par défaut). Ce n'est que si vous voulez absolument gérer les cas de merde, que -comme dans tout langage- vous allez avoir des soucis en mélangeant octets et caractères.

http://www.paroles.net/chanson/22017.1
- [^]Re: python 3.0
  
  Posté par ribwund () le 03/10/2008 à 15:16. (lien). Évalué à 3.
  En pratique pour les VCS et les outils de backup c'est la merde pour être multi-plateforme du coup. Sur mercurial les chemins de fichiers ne sont limités que par les limitations de unix (ou de la plateforme pour le checkout, on peut enregistrer des fichiers qui ne peuvent être checkouté que sous ext3).
  
  Je pense quand même que le coup des bytes est par forcement une amélioration (surtout le fait de passer la gestion de fichier en unicode, je vois pas comment ça peut marcher sous Unix, sauf si on décide que tout le monde utilise UTF-8 en locale, et même comme ça ça doit être possible de créer un fichier qui fera planter python, ou mal fonctionner un programme parce que le dev aura pas pensé à ce cas particulier et utilisera l'API unicode), en pratique ça complique beaucoup le code pour nous (j'espere juste que ça s'améliorera).
  
  Merci pour tes patches et ta volonté de faire avancer python sur ce problème.
  - [^]Re: python 3.0
    
    Posté par Victor STINNER (page perso, ) le 03/10/2008 à 16:31. (lien). Évalué à 2.
    Je pense quand même que le coup des bytes n'est pas forcement une amélioration
    
    Python2 et la grand majorité des langages de programmations n'utilisent que des octets, même s'ils nous mentent en utilisant des noms comme « char » (character) en C ou « str » (string) en Python. Bien qu'en Python2, on peut travailler en unicode, mais il faut le faire explicitement en utilisant le préfixe « u » (u'unicode').
    
    En pratique pour les VCS et les outils de backup c'est la merde pour être multi-plateforme du coup.
    
    Un outil de backup utilisera le type bytes sous Linux, et unicode (str) sous Windows. Les outils de backup représente qu'un faible pourcentage des applications. Les autres utiliseront unicode à tous les étages, ce qui simplifie énormément de choses (évite les horribles problèmes de mélange de charset).
    
    sauf si on décide que tout le monde utilise UTF-8 en locale
    
    C'est quand même de plus en plus le cas : UTF-8 est la locale par défaut sous Debian, Ubuntu, Mac OS X, etc.
    
    Je pense qu'on préfère rester compatible avec les systèmes qui ne parlent pas correctement Unicode (autorisent les chaînes mal encodées) parce que c'est plus facile (zéro effort) que de corriger le problème à la source (d'où vient cette chaîne pourrie ?). Pourquoi ne pas renommer correctement le fichier une fois pour toute plutôt que de devoir corriger tous les programmes pour gérer ce cas pourri ?
    - [^]Re: python 3.0
      
      Posté par ribwund () le 03/10/2008 à 16:44. (lien). Évalué à 3.
      Je pense qu'on préfère rester compatible avec les systèmes qui ne parlent pas correctement Unicode (autorisent les chaînes mal encodées) parce que c'est plus facile (zéro effort) que de corriger le problème à la source (d'où vient cette chaîne pourrie ?). Pourquoi ne pas renommer correctement le fichier une fois pour toute plutôt que de devoir corriger tous les programmes pour gérer ce cas pourri ?
      
      Sauf que dans ce cas c'est POSIX qu'il faut changer (rendre unicode obligatoire pour les noms de fichiers, et changer les systèmes de fichiers en conséquence), pour unix les noms de fichiers sont des octets.
      
      Sinon à mon avis il faudrait unifier les deux API (win et linux) et par exemple toujours convertir les chaînes unicode en UTF-8 sous windows quand on utilise l'API bytes, ainsi le code pour open() sous windows décoderait à partir de l'utf-8 quand on lui passe des bytes.
      - [^]Re: python 3.0
        
        Posté par Victor STINNER (page perso, ) le 03/10/2008 à 19:46. (lien). Évalué à 3.
        À mon avis il faudrait unifier Windows et Linux.
        
        Si tu veux polémiquer sur Python3, utilise plutôt la liste python-3000 et relit les long threads récent sur les noms de fichier unicode ou pas.
    - [^]Re: python 3.0
      
      Posté par freeze () le 03/10/2008 à 22:55. (lien). Évalué à 1.
      J'utilise UTF-8 tous les jours, mais je trouve aussi un peu génant de partir du principe que comme "c'est la conf par défaut sur certaines distributions", on oblige les gens à utiliser ça
      
      Où est le problème à avoir 2 versions ? Pour faire ça, les MFC (entre autres) permettent d'utiliser des LCHAR qui sont des char quand l'unicode n'est pas activé, et des wchar_t sinon.
      
      Alors forcément, en python il n'y a pas de préprocesseur ... mais bon, il doit bien y avoir une solution, non ?
      - [^]Re: python 3.0
        
        Posté par Antoine () le 03/10/2008 à 23:42. (lien). Évalué à 1.
        J'utilise UTF-8 tous les jours, mais je trouve aussi un peu génant de partir du principe que comme "c'est la conf par défaut sur certaines distributions", on oblige les gens à utiliser ça
        
        On n'oblige pas les gens à utiliser ça. Quand tu demandes un nom de fichier unicode sur un système Posix, des heuristiques sont utilisées pour découvrir le jeu de caractères en vigueur sur le système. Le problème c'est qu'en pratique chaque filesystem peut avoir un jeu de caractères différent...
        
        Où est le problème à avoir 2 versions ?
        
        Le problème c'est que ça t'oblige à avoir deux chemins de code différents dans ton application, selon que le nom de fichier est unicode ou 8 bits. Alors que ce serait beaucoup mieux si la couche IO de la stdlib s'en chargeait.
        
        [^]Re: python 3.0
        
        Posté par ribwund () le 03/10/2008 à 23:48. (lien). Évalué à 2.
        Le problème c'est qu'en pratique chaque filesystem peut avoir un jeu de caractères différent...
        
        Même chaque fichier, un cas très courant c'est 2 utilisateurs sur un même filsystem avec des locales différentes.
        
        [^]Re: python 3.0
        
        Posté par benoar (Jabber id, ) le 10/10/2008 à 02:36. (lien). Évalué à 3.
        Je voudrais pas dire, mais tous ces problèmes, ça n'est pas du ressort de python de les gérer. C'est pas comme si c'était pour s'adapter à une situation un petit peu problématique : là, c'est _vraiment_ le foutoir quand le système n'est même pas bien configuré pour avoir une locale uniforme. Mount propose toujours des options pour indiquer l'encodage des noms de fichiers, pour tous les FS. Si des noms de fichiers utilisent différents encodings dans le même filesystem, python n'y peut rien magiquement ...
        
        [^]Re: python 3.0
        
        Posté par ribwund () le 14/10/2008 à 15:17. (lien). Évalué à 1.
        Il peut donc ne rien faire et considérer les noms de fichiers comme une suite de bytes, comme tout les programmes UNIX.
        
        [^]Re: python 3.0
        
        Posté par Victor STINNER (page perso, ) le 15/10/2008 à 11:35. (lien). Évalué à 3.
        J'ai patché Python3 pour pouvoir gérer des noms de fichier sous forme de chaîne de caractères. Il suffit d'utiliser le type bytes (ex: b'pouet' au lieu de 'pouet') et les bonnes fonctions (ex: os.getcwdb() au lieu de os.getcwd()).

Revenir en haut de page

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Dépêche éditée par

Articles : Nouvelle version majeure de Python (2.6)

dix???

[^]Re: dix???

[^]Re: dix???

[^]Re: dix???

[^]Re: dix???

[^]Re: dix???

[^]Re: dix???

GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

[^]Re: GIL

2to3 … nostalgie … ou pas

[^]Re: 2to3 … nostalgie … ou pas

docs HS

[^]Re: docs HS

python 3.0

[^]Re: python 3.0

[^]Re: python 3.0

[^]Re: python 3.0

[^]Re: python 3.0

[^]Re: python 3.0

[^]Re: python 3.0

[^]Re: python 3.0

[^]Re: python 3.0

[^]Re: python 3.0

[^]Re: python 3.0

[^]Re: python 3.0