Une discussion fait rage en ce moment sur c.l.py concernant le PEP 3131
qui propose d'introduire le support des caractères non-ASCII dans les
identificateurs en Python. Par identificateurs, on entend bien sûr les
noms des variables, fonctions, classes, méthodes, etc... définis par
l'"utilisateur" (il n'est pas question de traduire les mot-clefs ou la
librairie standard).
Certains ont fait remarquer à juste titre que conduire cette discussion
sur un newsgroup 100% anglophone risquait de donner un résultat
franchement orienté - les personnes lisant et postant sur ce groupe ont
forcément un niveau d'anglais au moins correct - et qu'il serait bon de
"forwarder" (en voilà du français qu'il est bon) la discussion sur des
newsgroups non-anglophones.
Je ne vais toutefois pas traduire l'intégralité du PEP. Voici par contre
les questions à l'origine de la discussion, que j'essaie de traduire le
plus fidèlement possible:
- Est-ce que les caractères non-ASCII doivent être supportés dans les
identificateurs? Pourquoi?
- Si cette possibilité était offerte, l'utiliseriez-vous? Dans quels cas?
Voilà: battons-nous!
(NB: pour éviter d'éventuelles incompréhensions, je préfère donner mon
avis tout de suite: je suis résolument contre ce PEP. J'ai essayé de faire
en sorte que ça ne se voie pas dans ce qui précède, mais on ne sait
jamais; je préfère être clair.)
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Lorsque l'on travail sur l'analyse d'un texte l'encodage de celui-ci est une question cruciale. Ainsi que le format interne que vous utilisez pour manipuler les chaînes de caractères une fois que vous les avez décodé (pour python c'est UCS4 et pas utf-8 comme certains le supposent). Si plus de caractères sont acceptés pour créer les mots réservés et les
Les mots réservés ne comptent que pendant le lexer donc leur impact en terme de surcoup mémoire est égal à 0 une fois le .pyc dispo.
Une fois le pyc disponible, et c'est là que le bas blesse.
identifiants cela veut dire que l'analyse sera d'autant plus longue.
Le truc c'est que justement, les identifiant seraient encodés en utf-8.
Pourquoi en utf-8 ? J'utilise régulièrement l'utf-32 LE pour les sources et j'aurai besoin que les identifiants soient doit en encodage non compatible ?
Actuellement, le dico utilisé par Python pour stocker les identifiant des classes et des modules ne supporte comme clef que des string 8 bit, mais rien ne t'empêche de lui fournir comme clef une string qui ne passe pas en ASCII 7 bit pur. Exemple:
class toto(object): pass setattr(toto, "élément", 5)
Certes, j'ai déjà vu ce genre de code.
Le PEP 3131 ne changeras pas ça. Les dicos des objets continueront de restreindre les clefs à des strings 8 bits, c'est juste que le sens des caractères non ASCII sera officialisé comme étant de l'UTF-8 tout simplement. Il n'y aura aucun surcoup ou changement de comportement pour ceux qui ne font pas appel à cette fonctionnalité.
Mais je ne veux pas de l'utf-8, j'ai besoin d'avoir de l'utf-32 LE Évidemment, si je dois changer de plateforme il faut que l'uft-32 BE soit utilisable aussi.
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
Encolpe Degoute wrote:
Lorsque l'on travail sur l'analyse d'un texte l'encodage de celui-ci est
une question cruciale. Ainsi que le format interne que vous utilisez
pour manipuler les chaînes de caractères une fois que vous les avez
décodé (pour python c'est UCS4 et pas utf-8 comme certains le supposent).
Si plus de caractères sont acceptés pour créer les mots réservés et les
Les mots réservés ne comptent que pendant le lexer donc leur impact en terme
de surcoup mémoire est égal à 0 une fois le .pyc dispo.
Une fois le pyc disponible, et c'est là que le bas blesse.
identifiants cela veut dire que l'analyse sera d'autant plus longue.
Le truc c'est que justement, les identifiant seraient encodés en utf-8.
Pourquoi en utf-8 ?
J'utilise régulièrement l'utf-32 LE pour les sources et j'aurai besoin
que les identifiants soient doit en encodage non compatible ?
Actuellement, le dico utilisé par Python pour stocker les identifiant des
classes et des modules ne supporte comme clef que des string 8 bit, mais
rien ne t'empêche de lui fournir comme clef une string qui ne passe pas en
ASCII 7 bit pur. Exemple:
class toto(object): pass
setattr(toto, "élément", 5)
Certes, j'ai déjà vu ce genre de code.
Le PEP 3131 ne changeras pas ça. Les dicos des objets continueront de
restreindre les clefs à des strings 8 bits, c'est juste que le sens des
caractères non ASCII sera officialisé comme étant de l'UTF-8 tout
simplement. Il n'y aura aucun surcoup ou changement de comportement pour
ceux qui ne font pas appel à cette fonctionnalité.
Mais je ne veux pas de l'utf-8, j'ai besoin d'avoir de l'utf-32 LE
Évidemment, si je dois changer de plateforme il faut que l'uft-32 BE
soit utilisable aussi.
--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales
Lorsque l'on travail sur l'analyse d'un texte l'encodage de celui-ci est une question cruciale. Ainsi que le format interne que vous utilisez pour manipuler les chaînes de caractères une fois que vous les avez décodé (pour python c'est UCS4 et pas utf-8 comme certains le supposent). Si plus de caractères sont acceptés pour créer les mots réservés et les
Les mots réservés ne comptent que pendant le lexer donc leur impact en terme de surcoup mémoire est égal à 0 une fois le .pyc dispo.
Une fois le pyc disponible, et c'est là que le bas blesse.
identifiants cela veut dire que l'analyse sera d'autant plus longue.
Le truc c'est que justement, les identifiant seraient encodés en utf-8.
Pourquoi en utf-8 ? J'utilise régulièrement l'utf-32 LE pour les sources et j'aurai besoin que les identifiants soient doit en encodage non compatible ?
Actuellement, le dico utilisé par Python pour stocker les identifiant des classes et des modules ne supporte comme clef que des string 8 bit, mais rien ne t'empêche de lui fournir comme clef une string qui ne passe pas en ASCII 7 bit pur. Exemple:
class toto(object): pass setattr(toto, "élément", 5)
Certes, j'ai déjà vu ce genre de code.
Le PEP 3131 ne changeras pas ça. Les dicos des objets continueront de restreindre les clefs à des strings 8 bits, c'est juste que le sens des caractères non ASCII sera officialisé comme étant de l'UTF-8 tout simplement. Il n'y aura aucun surcoup ou changement de comportement pour ceux qui ne font pas appel à cette fonctionnalité.
Mais je ne veux pas de l'utf-8, j'ai besoin d'avoir de l'utf-32 LE Évidemment, si je dois changer de plateforme il faut que l'uft-32 BE soit utilisable aussi.
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
Christophe Cavalaria
Encolpe Degoute wrote:
Encolpe Degoute wrote:
Lorsque l'on travail sur l'analyse d'un texte l'encodage de celui-ci est une question cruciale. Ainsi que le format interne que vous utilisez pour manipuler les chaînes de caractères une fois que vous les avez décodé (pour python c'est UCS4 et pas utf-8 comme certains le supposent). Si plus de caractères sont acceptés pour créer les mots réservés et les
Les mots réservés ne comptent que pendant le lexer donc leur impact en terme de surcoup mémoire est égal à 0 une fois le .pyc dispo.
Une fois le pyc disponible, et c'est là que le bas blesse.
identifiants cela veut dire que l'analyse sera d'autant plus longue.
Le truc c'est que justement, les identifiant seraient encodés en utf-8.
Pourquoi en utf-8 ? J'utilise régulièrement l'utf-32 LE pour les sources et j'aurai besoin que les identifiants soient doit en encodage non compatible ?
J'ai du mal à comprendre ça. Déjà, il me semblait que le format utf-32 n'était supporté par Python pour le code source.
Le PEP 3131 ne changeras pas ça. Les dicos des objets continueront de restreindre les clefs à des strings 8 bits, c'est juste que le sens des caractères non ASCII sera officialisé comme étant de l'UTF-8 tout simplement. Il n'y aura aucun surcoup ou changement de comportement pour ceux qui ne font pas appel à cette fonctionnalité.
Mais je ne veux pas de l'utf-8, j'ai besoin d'avoir de l'utf-32 LE Évidemment, si je dois changer de plateforme il faut que l'uft-32 BE soit utilisable aussi.
Ah mais la on ne parle plus de la même chose. Moi je parle de la représentation en mémoire du dico stockant les propriétés des objets/modules. Ceci est un détail d'implementation qui ne nous concerne pas directement.
Vous, vous parlez de quelque chose que j'ai du mal à cerner. Si c'est le format de fichiers de données (analyse d'un texte ?), cela n'a rien à voir avec le PEP 3131 et vous n'avez absolument rien à craindre de ce coté.
Si c'est le format des fichiers .py compilés par Python, le format de ceux-ci est complètement indépendants du résultat obtenu après compilation et n'a aucune influence sur le comportement futur, du moment que le compilateur à bien été renseigné sur le format à utiliser.
Encolpe Degoute wrote:
Encolpe Degoute wrote:
Lorsque l'on travail sur l'analyse d'un texte l'encodage de celui-ci est
une question cruciale. Ainsi que le format interne que vous utilisez
pour manipuler les chaînes de caractères une fois que vous les avez
décodé (pour python c'est UCS4 et pas utf-8 comme certains le
supposent). Si plus de caractères sont acceptés pour créer les mots
réservés et les
Les mots réservés ne comptent que pendant le lexer donc leur impact en
terme de surcoup mémoire est égal à 0 une fois le .pyc dispo.
Une fois le pyc disponible, et c'est là que le bas blesse.
identifiants cela veut dire que l'analyse sera d'autant plus longue.
Le truc c'est que justement, les identifiant seraient encodés en utf-8.
Pourquoi en utf-8 ?
J'utilise régulièrement l'utf-32 LE pour les sources et j'aurai besoin
que les identifiants soient doit en encodage non compatible ?
J'ai du mal à comprendre ça. Déjà, il me semblait que le format utf-32
n'était supporté par Python pour le code source.
Le PEP 3131 ne changeras pas ça. Les dicos des objets continueront de
restreindre les clefs à des strings 8 bits, c'est juste que le sens des
caractères non ASCII sera officialisé comme étant de l'UTF-8 tout
simplement. Il n'y aura aucun surcoup ou changement de comportement pour
ceux qui ne font pas appel à cette fonctionnalité.
Mais je ne veux pas de l'utf-8, j'ai besoin d'avoir de l'utf-32 LE
Évidemment, si je dois changer de plateforme il faut que l'uft-32 BE
soit utilisable aussi.
Ah mais la on ne parle plus de la même chose. Moi je parle de la
représentation en mémoire du dico stockant les propriétés des
objets/modules. Ceci est un détail d'implementation qui ne nous concerne
pas directement.
Vous, vous parlez de quelque chose que j'ai du mal à cerner. Si c'est le
format de fichiers de données (analyse d'un texte ?), cela n'a rien à voir
avec le PEP 3131 et vous n'avez absolument rien à craindre de ce coté.
Si c'est le format des fichiers .py compilés par Python, le format de
ceux-ci est complètement indépendants du résultat obtenu après compilation
et n'a aucune influence sur le comportement futur, du moment que le
compilateur à bien été renseigné sur le format à utiliser.
Lorsque l'on travail sur l'analyse d'un texte l'encodage de celui-ci est une question cruciale. Ainsi que le format interne que vous utilisez pour manipuler les chaînes de caractères une fois que vous les avez décodé (pour python c'est UCS4 et pas utf-8 comme certains le supposent). Si plus de caractères sont acceptés pour créer les mots réservés et les
Les mots réservés ne comptent que pendant le lexer donc leur impact en terme de surcoup mémoire est égal à 0 une fois le .pyc dispo.
Une fois le pyc disponible, et c'est là que le bas blesse.
identifiants cela veut dire que l'analyse sera d'autant plus longue.
Le truc c'est que justement, les identifiant seraient encodés en utf-8.
Pourquoi en utf-8 ? J'utilise régulièrement l'utf-32 LE pour les sources et j'aurai besoin que les identifiants soient doit en encodage non compatible ?
J'ai du mal à comprendre ça. Déjà, il me semblait que le format utf-32 n'était supporté par Python pour le code source.
Le PEP 3131 ne changeras pas ça. Les dicos des objets continueront de restreindre les clefs à des strings 8 bits, c'est juste que le sens des caractères non ASCII sera officialisé comme étant de l'UTF-8 tout simplement. Il n'y aura aucun surcoup ou changement de comportement pour ceux qui ne font pas appel à cette fonctionnalité.
Mais je ne veux pas de l'utf-8, j'ai besoin d'avoir de l'utf-32 LE Évidemment, si je dois changer de plateforme il faut que l'uft-32 BE soit utilisable aussi.
Ah mais la on ne parle plus de la même chose. Moi je parle de la représentation en mémoire du dico stockant les propriétés des objets/modules. Ceci est un détail d'implementation qui ne nous concerne pas directement.
Vous, vous parlez de quelque chose que j'ai du mal à cerner. Si c'est le format de fichiers de données (analyse d'un texte ?), cela n'a rien à voir avec le PEP 3131 et vous n'avez absolument rien à craindre de ce coté.
Si c'est le format des fichiers .py compilés par Python, le format de ceux-ci est complètement indépendants du résultat obtenu après compilation et n'a aucune influence sur le comportement futur, du moment que le compilateur à bien été renseigné sur le format à utiliser.
Encolpe Degoute
Encolpe Degoute wrote:
Encolpe Degoute wrote:
Lorsque l'on travail sur l'analyse d'un texte l'encodage de celui-ci est une question cruciale. Ainsi que le format interne que vous utilisez pour manipuler les chaînes de caractères une fois que vous les avez décodé (pour python c'est UCS4 et pas utf-8 comme certains le supposent). Si plus de caractères sont acceptés pour créer les mots réservés et les Les mots réservés ne comptent que pendant le lexer donc leur impact en
terme de surcoup mémoire est égal à 0 une fois le .pyc dispo. Une fois le pyc disponible, et c'est là que le bas blesse.
identifiants cela veut dire que l'analyse sera d'autant plus longue. Le truc c'est que justement, les identifiant seraient encodés en utf-8.
Pourquoi en utf-8 ?
J'utilise régulièrement l'utf-32 LE pour les sources et j'aurai besoin que les identifiants soient doit en encodage non compatible ?
J'ai du mal à comprendre ça. Déjà, il me semblait que le format utf-32 n'était supporté par Python pour le code source.
Comme l'utf-8.
Le PEP 3131 ne changeras pas ça. Les dicos des objets continueront de restreindre les clefs à des strings 8 bits, c'est juste que le sens des caractères non ASCII sera officialisé comme étant de l'UTF-8 tout simplement. Il n'y aura aucun surcoup ou changement de comportement pour ceux qui ne font pas appel à cette fonctionnalité. Mais je ne veux pas de l'utf-8, j'ai besoin d'avoir de l'utf-32 LE
Évidemment, si je dois changer de plateforme il faut que l'uft-32 BE soit utilisable aussi.
Ah mais la on ne parle plus de la même chose. Moi je parle de la représentation en mémoire du dico stockant les propriétés des objets/modules. Ceci est un détail d'implementation qui ne nous concerne pas directement.
Il serait alors plus intéressant de les stocker en UCS4 qu'en utf-8.
Vous, vous parlez de quelque chose que j'ai du mal à cerner. Si c'est le format de fichiers de données (analyse d'un texte ?), cela n'a rien à voir avec le PEP 3131 et vous n'avez absolument rien à craindre de ce coté.
Je parle bien de la gestion des identifiants d'un point de vue que vous n'avez pas encore envisagé.
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
Encolpe Degoute wrote:
Encolpe Degoute wrote:
Lorsque l'on travail sur l'analyse d'un texte l'encodage de celui-ci est
une question cruciale. Ainsi que le format interne que vous utilisez
pour manipuler les chaînes de caractères une fois que vous les avez
décodé (pour python c'est UCS4 et pas utf-8 comme certains le
supposent). Si plus de caractères sont acceptés pour créer les mots
réservés et les
Les mots réservés ne comptent que pendant le lexer donc leur impact en
terme de surcoup mémoire est égal à 0 une fois le .pyc dispo.
Une fois le pyc disponible, et c'est là que le bas blesse.
identifiants cela veut dire que l'analyse sera d'autant plus longue.
Le truc c'est que justement, les identifiant seraient encodés en utf-8.
Pourquoi en utf-8 ?
J'utilise régulièrement l'utf-32 LE pour les sources et j'aurai besoin
que les identifiants soient doit en encodage non compatible ?
J'ai du mal à comprendre ça. Déjà, il me semblait que le format utf-32
n'était supporté par Python pour le code source.
Comme l'utf-8.
Le PEP 3131 ne changeras pas ça. Les dicos des objets continueront de
restreindre les clefs à des strings 8 bits, c'est juste que le sens des
caractères non ASCII sera officialisé comme étant de l'UTF-8 tout
simplement. Il n'y aura aucun surcoup ou changement de comportement pour
ceux qui ne font pas appel à cette fonctionnalité.
Mais je ne veux pas de l'utf-8, j'ai besoin d'avoir de l'utf-32 LE
Évidemment, si je dois changer de plateforme il faut que l'uft-32 BE
soit utilisable aussi.
Ah mais la on ne parle plus de la même chose. Moi je parle de la
représentation en mémoire du dico stockant les propriétés des
objets/modules. Ceci est un détail d'implementation qui ne nous concerne
pas directement.
Il serait alors plus intéressant de les stocker en UCS4 qu'en utf-8.
Vous, vous parlez de quelque chose que j'ai du mal à cerner. Si c'est le
format de fichiers de données (analyse d'un texte ?), cela n'a rien à voir
avec le PEP 3131 et vous n'avez absolument rien à craindre de ce coté.
Je parle bien de la gestion des identifiants d'un point de vue que vous
n'avez pas encore envisagé.
--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales
Lorsque l'on travail sur l'analyse d'un texte l'encodage de celui-ci est une question cruciale. Ainsi que le format interne que vous utilisez pour manipuler les chaînes de caractères une fois que vous les avez décodé (pour python c'est UCS4 et pas utf-8 comme certains le supposent). Si plus de caractères sont acceptés pour créer les mots réservés et les Les mots réservés ne comptent que pendant le lexer donc leur impact en
terme de surcoup mémoire est égal à 0 une fois le .pyc dispo. Une fois le pyc disponible, et c'est là que le bas blesse.
identifiants cela veut dire que l'analyse sera d'autant plus longue. Le truc c'est que justement, les identifiant seraient encodés en utf-8.
Pourquoi en utf-8 ?
J'utilise régulièrement l'utf-32 LE pour les sources et j'aurai besoin que les identifiants soient doit en encodage non compatible ?
J'ai du mal à comprendre ça. Déjà, il me semblait que le format utf-32 n'était supporté par Python pour le code source.
Comme l'utf-8.
Le PEP 3131 ne changeras pas ça. Les dicos des objets continueront de restreindre les clefs à des strings 8 bits, c'est juste que le sens des caractères non ASCII sera officialisé comme étant de l'UTF-8 tout simplement. Il n'y aura aucun surcoup ou changement de comportement pour ceux qui ne font pas appel à cette fonctionnalité. Mais je ne veux pas de l'utf-8, j'ai besoin d'avoir de l'utf-32 LE
Évidemment, si je dois changer de plateforme il faut que l'uft-32 BE soit utilisable aussi.
Ah mais la on ne parle plus de la même chose. Moi je parle de la représentation en mémoire du dico stockant les propriétés des objets/modules. Ceci est un détail d'implementation qui ne nous concerne pas directement.
Il serait alors plus intéressant de les stocker en UCS4 qu'en utf-8.
Vous, vous parlez de quelque chose que j'ai du mal à cerner. Si c'est le format de fichiers de données (analyse d'un texte ?), cela n'a rien à voir avec le PEP 3131 et vous n'avez absolument rien à craindre de ce coté.
Je parle bien de la gestion des identifiants d'un point de vue que vous n'avez pas encore envisagé.
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
Christophe Cavalaria
Encolpe Degoute wrote:
J'ai du mal à comprendre ça. Déjà, il me semblait que le format utf-32 n'était supporté par Python pour le code source.
Comme l'utf-8.
C'est faux. Les sources Python en utf-8 sont supportés depuis bien longtemps (Python 2.2). C'est les résultats du PEP 263 : http://www.python.org/dev/peps/pep-0263/
Le PEP 3131 ne changeras pas ça. Les dicos des objets continueront de restreindre les clefs à des strings 8 bits, c'est juste que le sens des caractères non ASCII sera officialisé comme étant de l'UTF-8 tout simplement. Il n'y aura aucun surcoup ou changement de comportement pour ceux qui ne font pas appel à cette fonctionnalité. Mais je ne veux pas de l'utf-8, j'ai besoin d'avoir de l'utf-32 LE
Évidemment, si je dois changer de plateforme il faut que l'uft-32 BE soit utilisable aussi.
Ah mais la on ne parle plus de la même chose. Moi je parle de la représentation en mémoire du dico stockant les propriétés des objets/modules. Ceci est un détail d'implementation qui ne nous concerne pas directement.
Il serait alors plus intéressant de les stocker en UCS4 qu'en utf-8.
Pas vraiment car cela aura un impact non négligeable sur les performances. Dans ce cas, il est assez clair que 99.999% des identifiant Python seront bien plus économes en mémoire en utf-8 qu'en ucs-4. Et pour un tableau de hashage, être plus court veux dire passer moins de temps à calculer le hash et passer moins de temps après à comparer les clefs avec celles trouvées. utf-8 est clairement ici la meilleure solution. De plus, vu qu'actuellement l'ensemble des identifiant Python sont en ASCII, choisir l'utf-8 veux dire qu'il n'y aura absolument aucun impact sur le comportement ni sur les performances du code existant. La compatibilité est telle qu'il y a 99% de chances que les pyc compilés sans le changement soient directement compatibles avec une version avec, et de grandes chances pour que l'inverse soit vrai aussi.
Ensuite, faire ce genre de changement necessiterais de repasser sur TOUT le code C qui manipuler ces dictionaires avec des tableaux de 8bits pour qu'ils utilisents de tableaux de 32bits. La quantité de travail à fournir serait assez colossale et source de nombreux bugs.
Pensez bien qu'avec toute la polémique autour de cette PEP, si en plus il fallait faire accepter une grosse perte de performance et l'introduction potentielle de nombreux bugs, la PEP n'aurait sans doute même pas été proposée.
Vous, vous parlez de quelque chose que j'ai du mal à cerner. Si c'est le format de fichiers de données (analyse d'un texte ?), cela n'a rien à voir avec le PEP 3131 et vous n'avez absolument rien à craindre de ce coté.
Je parle bien de la gestion des identifiants d'un point de vue que vous n'avez pas encore envisagé.
D'ailleurs, ce serait pas mal si vous pouviez expliquer au juste en quoi cela vous importe que la représentation interne soit en ucs-4. Il y a tellement de raisons de ne pas passer à cette représentation et aucune bonne raison de le faire au lieu de utf-8 :)
Encolpe Degoute wrote:
J'ai du mal à comprendre ça. Déjà, il me semblait que le format utf-32
n'était supporté par Python pour le code source.
Comme l'utf-8.
C'est faux. Les sources Python en utf-8 sont supportés depuis bien longtemps
(Python 2.2). C'est les résultats du PEP 263 :
http://www.python.org/dev/peps/pep-0263/
Le PEP 3131 ne changeras pas ça. Les dicos des objets continueront de
restreindre les clefs à des strings 8 bits, c'est juste que le sens des
caractères non ASCII sera officialisé comme étant de l'UTF-8 tout
simplement. Il n'y aura aucun surcoup ou changement de comportement
pour ceux qui ne font pas appel à cette fonctionnalité.
Mais je ne veux pas de l'utf-8, j'ai besoin d'avoir de l'utf-32 LE
Évidemment, si je dois changer de plateforme il faut que l'uft-32 BE
soit utilisable aussi.
Ah mais la on ne parle plus de la même chose. Moi je parle de la
représentation en mémoire du dico stockant les propriétés des
objets/modules. Ceci est un détail d'implementation qui ne nous concerne
pas directement.
Il serait alors plus intéressant de les stocker en UCS4 qu'en utf-8.
Pas vraiment car cela aura un impact non négligeable sur les performances.
Dans ce cas, il est assez clair que 99.999% des identifiant Python seront
bien plus économes en mémoire en utf-8 qu'en ucs-4. Et pour un tableau de
hashage, être plus court veux dire passer moins de temps à calculer le hash
et passer moins de temps après à comparer les clefs avec celles trouvées.
utf-8 est clairement ici la meilleure solution. De plus, vu qu'actuellement
l'ensemble des identifiant Python sont en ASCII, choisir l'utf-8 veux dire
qu'il n'y aura absolument aucun impact sur le comportement ni sur les
performances du code existant. La compatibilité est telle qu'il y a 99% de
chances que les pyc compilés sans le changement soient directement
compatibles avec une version avec, et de grandes chances pour que l'inverse
soit vrai aussi.
Ensuite, faire ce genre de changement necessiterais de repasser sur TOUT le
code C qui manipuler ces dictionaires avec des tableaux de 8bits pour
qu'ils utilisents de tableaux de 32bits. La quantité de travail à fournir
serait assez colossale et source de nombreux bugs.
Pensez bien qu'avec toute la polémique autour de cette PEP, si en plus il
fallait faire accepter une grosse perte de performance et l'introduction
potentielle de nombreux bugs, la PEP n'aurait sans doute même pas été
proposée.
Vous, vous parlez de quelque chose que j'ai du mal à cerner. Si c'est le
format de fichiers de données (analyse d'un texte ?), cela n'a rien à
voir avec le PEP 3131 et vous n'avez absolument rien à craindre de ce
coté.
Je parle bien de la gestion des identifiants d'un point de vue que vous
n'avez pas encore envisagé.
D'ailleurs, ce serait pas mal si vous pouviez expliquer au juste en quoi
cela vous importe que la représentation interne soit en ucs-4. Il y a
tellement de raisons de ne pas passer à cette représentation et aucune
bonne raison de le faire au lieu de utf-8 :)
J'ai du mal à comprendre ça. Déjà, il me semblait que le format utf-32 n'était supporté par Python pour le code source.
Comme l'utf-8.
C'est faux. Les sources Python en utf-8 sont supportés depuis bien longtemps (Python 2.2). C'est les résultats du PEP 263 : http://www.python.org/dev/peps/pep-0263/
Le PEP 3131 ne changeras pas ça. Les dicos des objets continueront de restreindre les clefs à des strings 8 bits, c'est juste que le sens des caractères non ASCII sera officialisé comme étant de l'UTF-8 tout simplement. Il n'y aura aucun surcoup ou changement de comportement pour ceux qui ne font pas appel à cette fonctionnalité. Mais je ne veux pas de l'utf-8, j'ai besoin d'avoir de l'utf-32 LE
Évidemment, si je dois changer de plateforme il faut que l'uft-32 BE soit utilisable aussi.
Ah mais la on ne parle plus de la même chose. Moi je parle de la représentation en mémoire du dico stockant les propriétés des objets/modules. Ceci est un détail d'implementation qui ne nous concerne pas directement.
Il serait alors plus intéressant de les stocker en UCS4 qu'en utf-8.
Pas vraiment car cela aura un impact non négligeable sur les performances. Dans ce cas, il est assez clair que 99.999% des identifiant Python seront bien plus économes en mémoire en utf-8 qu'en ucs-4. Et pour un tableau de hashage, être plus court veux dire passer moins de temps à calculer le hash et passer moins de temps après à comparer les clefs avec celles trouvées. utf-8 est clairement ici la meilleure solution. De plus, vu qu'actuellement l'ensemble des identifiant Python sont en ASCII, choisir l'utf-8 veux dire qu'il n'y aura absolument aucun impact sur le comportement ni sur les performances du code existant. La compatibilité est telle qu'il y a 99% de chances que les pyc compilés sans le changement soient directement compatibles avec une version avec, et de grandes chances pour que l'inverse soit vrai aussi.
Ensuite, faire ce genre de changement necessiterais de repasser sur TOUT le code C qui manipuler ces dictionaires avec des tableaux de 8bits pour qu'ils utilisents de tableaux de 32bits. La quantité de travail à fournir serait assez colossale et source de nombreux bugs.
Pensez bien qu'avec toute la polémique autour de cette PEP, si en plus il fallait faire accepter une grosse perte de performance et l'introduction potentielle de nombreux bugs, la PEP n'aurait sans doute même pas été proposée.
Vous, vous parlez de quelque chose que j'ai du mal à cerner. Si c'est le format de fichiers de données (analyse d'un texte ?), cela n'a rien à voir avec le PEP 3131 et vous n'avez absolument rien à craindre de ce coté.
Je parle bien de la gestion des identifiants d'un point de vue que vous n'avez pas encore envisagé.
D'ailleurs, ce serait pas mal si vous pouviez expliquer au juste en quoi cela vous importe que la représentation interne soit en ucs-4. Il y a tellement de raisons de ne pas passer à cette représentation et aucune bonne raison de le faire au lieu de utf-8 :)
Encolpe Degoute
D'ailleurs, ce serait pas mal si vous pouviez expliquer au juste en quoi cela vous importe que la représentation interne soit en ucs-4. Il y a tellement de raisons de ne pas passer à cette représentation et aucune bonne raison de le faire au lieu de utf-8 :)
En fait je voulais seulement une bonne argumentation qui explique le point de vue de ce PEP. L'argument disant « il *FAUT* passer en français dans python parce que nous sommes français » a autant de poids que « je gueule le plus fort donc j'ai raison ». Votre exposé pose des bases beaucoup plus solides que les argumentaires précédents même si je ne vois toujours pas l'intérêt de la chose.
À vrai dire je m'en contrefous car pour moi cela ne changera rien car je bosse avec des projets multinationaux ou l'ascii 7 est de rigueur pour le code. Pour l'instant je n'ai qu'un seul client qui m'a demandé expressément de franciser mon code mais c'était beaucoup plus pour essayer de faire trainer le projet et masquer sa propre incompétence que pour autre chose.
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
D'ailleurs, ce serait pas mal si vous pouviez expliquer au juste en quoi
cela vous importe que la représentation interne soit en ucs-4. Il y a
tellement de raisons de ne pas passer à cette représentation et aucune
bonne raison de le faire au lieu de utf-8 :)
En fait je voulais seulement une bonne argumentation qui explique le
point de vue de ce PEP.
L'argument disant « il *FAUT* passer en français dans python parce que
nous sommes français » a autant de poids que « je gueule le plus fort
donc j'ai raison ».
Votre exposé pose des bases beaucoup plus solides que les argumentaires
précédents même si je ne vois toujours pas l'intérêt de la chose.
À vrai dire je m'en contrefous car pour moi cela ne changera rien car je
bosse avec des projets multinationaux ou l'ascii 7 est de rigueur pour
le code. Pour l'instant je n'ai qu'un seul client qui m'a demandé
expressément de franciser mon code mais c'était beaucoup plus pour
essayer de faire trainer le projet et masquer sa propre incompétence que
pour autre chose.
--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales
D'ailleurs, ce serait pas mal si vous pouviez expliquer au juste en quoi cela vous importe que la représentation interne soit en ucs-4. Il y a tellement de raisons de ne pas passer à cette représentation et aucune bonne raison de le faire au lieu de utf-8 :)
En fait je voulais seulement une bonne argumentation qui explique le point de vue de ce PEP. L'argument disant « il *FAUT* passer en français dans python parce que nous sommes français » a autant de poids que « je gueule le plus fort donc j'ai raison ». Votre exposé pose des bases beaucoup plus solides que les argumentaires précédents même si je ne vois toujours pas l'intérêt de la chose.
À vrai dire je m'en contrefous car pour moi cela ne changera rien car je bosse avec des projets multinationaux ou l'ascii 7 est de rigueur pour le code. Pour l'instant je n'ai qu'un seul client qui m'a demandé expressément de franciser mon code mais c'était beaucoup plus pour essayer de faire trainer le projet et masquer sa propre incompétence que pour autre chose.
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
hg
MCI, Shadok Gouroudoudou wrote:
Bonjour !
On a compris tu es anglo-fan.
Mais, comme rien ne t'empêches de le rester, tu peux très bien acdepter que d'autres aient un autre point de vue.
Autrement dit, pour le PEP-3131, tu pourrais dire : "je ne l'utiliserai pas, mais, si ça peut servir à d'autres, pourquoi pas ? "
-- @-salutations
Michel Claveau
je ne l'utiliserai pas, mais, si ça peut servir à d'autres, pourquoi pas ?
hg
MCI, Shadok Gouroudoudou wrote:
Bonjour !
On a compris tu es anglo-fan.
Mais, comme rien ne t'empêches de le rester, tu peux très bien acdepter
que d'autres aient un autre point de vue.
Autrement dit, pour le PEP-3131, tu pourrais dire : "je ne l'utiliserai
pas, mais, si ça peut servir à d'autres, pourquoi pas ? "
--
@-salutations
Michel Claveau
je ne l'utiliserai pas, mais, si ça peut servir à d'autres, pourquoi pas ?
Mais, comme rien ne t'empêches de le rester, tu peux très bien acdepter que d'autres aient un autre point de vue.
Autrement dit, pour le PEP-3131, tu pourrais dire : "je ne l'utiliserai pas, mais, si ça peut servir à d'autres, pourquoi pas ? "
-- @-salutations
Michel Claveau
je ne l'utiliserai pas, mais, si ça peut servir à d'autres, pourquoi pas ?
hg
jean-michel bain-cornu
Quand je discute avec les responsables informatiques anglais, ils sont étonnés par la créativité fonctionnelle des informaticiens français. Mais ils ont peur de ne jamais pourvoir en maîtriser les logiciels. En pratique, ils misent sur la simplicité, limitent les développements, et, en réalité ... ne maîtrisent pas leurs progiciels.
Attention à ne pas généraliser d'après ton expérience spécifique. D'après la mienne, je ne serais pas aussi optimiste sur les points que tu évoques.
Quand je discute avec les responsables informatiques anglais, ils sont
étonnés par la créativité fonctionnelle des informaticiens français.
Mais ils ont peur de ne jamais pourvoir en maîtriser les logiciels.
En pratique, ils misent sur la simplicité, limitent les développements,
et, en réalité ... ne maîtrisent pas leurs progiciels.
Attention à ne pas généraliser d'après ton expérience spécifique.
D'après la mienne, je ne serais pas aussi optimiste sur les points que
tu évoques.
Quand je discute avec les responsables informatiques anglais, ils sont étonnés par la créativité fonctionnelle des informaticiens français. Mais ils ont peur de ne jamais pourvoir en maîtriser les logiciels. En pratique, ils misent sur la simplicité, limitent les développements, et, en réalité ... ne maîtrisent pas leurs progiciels.
Attention à ne pas généraliser d'après ton expérience spécifique. D'après la mienne, je ne serais pas aussi optimiste sur les points que tu évoques.
jean-michel bain-cornu
Une discussion fait rage en ce moment sur c.l.py concernant le PEP 3131 qui propose d'introduire le support des caractères non-ASCII dans les identificateurs en Python. Par identificateurs, on entend bien sûr les noms des variables, fonctions, classes, méthodes, etc... définis par l'"utilisateur" (il n'est pas question de traduire les mot-clefs ou la librairie standard).
Comme c'est vendredi, et qu'apparemment c'est le jour du troll, je me demande s'il y a un anglophile qui va faire un 'report' de tout ces échanges pour nos amis anglophones ?
Une discussion fait rage en ce moment sur c.l.py concernant le PEP 3131
qui propose d'introduire le support des caractères non-ASCII dans les
identificateurs en Python. Par identificateurs, on entend bien sûr les
noms des variables, fonctions, classes, méthodes, etc... définis par
l'"utilisateur" (il n'est pas question de traduire les mot-clefs ou la
librairie standard).
Comme c'est vendredi, et qu'apparemment c'est le jour du troll, je me
demande s'il y a un anglophile qui va faire un 'report' de tout ces
échanges pour nos amis anglophones ?
Une discussion fait rage en ce moment sur c.l.py concernant le PEP 3131 qui propose d'introduire le support des caractères non-ASCII dans les identificateurs en Python. Par identificateurs, on entend bien sûr les noms des variables, fonctions, classes, méthodes, etc... définis par l'"utilisateur" (il n'est pas question de traduire les mot-clefs ou la librairie standard).
Comme c'est vendredi, et qu'apparemment c'est le jour du troll, je me demande s'il y a un anglophile qui va faire un 'report' de tout ces échanges pour nos amis anglophones ?
hg
MCI, Shadok Gouroudoudou wrote:
Bonjour !
Perso, même si ça passe, je continuerais à conserver des identificateurs comme actuellement. Mais je comprend ceux qui veulent pouvoir utiliser les caractères dans leur langue.
Position très sage. Donc, chacun fait comme il veut, et les cows seront bien gardées.
-- @-salutations
Michel Claveau
Et le shador à l'école laïque aussi ? ;-)
hg
MCI, Shadok Gouroudoudou wrote:
Bonjour !
Perso, même si ça passe, je continuerais à conserver des
identificateurs comme actuellement. Mais je comprend ceux qui veulent
pouvoir utiliser les caractères dans leur langue.
Position très sage. Donc, chacun fait comme il veut, et les cows seront
bien gardées.
Perso, même si ça passe, je continuerais à conserver des identificateurs comme actuellement. Mais je comprend ceux qui veulent pouvoir utiliser les caractères dans leur langue.
Position très sage. Donc, chacun fait comme il veut, et les cows seront bien gardées.
-- @-salutations
Michel Claveau
Et le shador à l'école laïque aussi ? ;-)
hg
Eric Brunel
On Fri, 18 May 2007 08:39:39 +0200, jean-michel bain-cornu wrote:
Une discussion fait rage en ce moment sur c.l.py concernant le PEP 3131 qui propose d'introduire le support des caractères non-ASCII dans les identificateurs en Python. Par identificateurs, on entend bien sûr les noms des variables, fonctions, classes, méthodes, etc... définis par l'"utilisateur" (il n'est pas question de traduire les mot-clefs ou la librairie standard).
Comme c'est vendredi, et qu'apparemment c'est le jour du troll, je me demande s'il y a un anglophile qui va faire un 'report' de tout ces échanges pour nos amis anglophones ?
Et ben je peux même me dévouer, vu qu'en fin de compte, le résumé va être simple: tant du point de vue de l'"animation" de la discussion, du nombre de "pour" et du nombre de "contre" que des arguments employés, il se passe exactement la même chose sur f.c.l.py que sur c.l.py...
Le moins qu'on puisse dire est que ce PEP déchaîne les passions... -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
On Fri, 18 May 2007 08:39:39 +0200, jean-michel bain-cornu
<pythonnews@nospam.jmbc.fr> wrote:
Une discussion fait rage en ce moment sur c.l.py concernant le PEP 3131
qui propose d'introduire le support des caractères non-ASCII dans les
identificateurs en Python. Par identificateurs, on entend bien sûr les
noms des variables, fonctions, classes, méthodes, etc... définis par
l'"utilisateur" (il n'est pas question de traduire les mot-clefs ou la
librairie standard).
Comme c'est vendredi, et qu'apparemment c'est le jour du troll, je me
demande s'il y a un anglophile qui va faire un 'report' de tout ces
échanges pour nos amis anglophones ?
Et ben je peux même me dévouer, vu qu'en fin de compte, le résumé va être
simple: tant du point de vue de l'"animation" de la discussion, du nombre
de "pour" et du nombre de "contre" que des arguments employés, il se passe
exactement la même chose sur f.c.l.py que sur c.l.py...
Le moins qu'on puisse dire est que ce PEP déchaîne les passions...
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
On Fri, 18 May 2007 08:39:39 +0200, jean-michel bain-cornu wrote:
Une discussion fait rage en ce moment sur c.l.py concernant le PEP 3131 qui propose d'introduire le support des caractères non-ASCII dans les identificateurs en Python. Par identificateurs, on entend bien sûr les noms des variables, fonctions, classes, méthodes, etc... définis par l'"utilisateur" (il n'est pas question de traduire les mot-clefs ou la librairie standard).
Comme c'est vendredi, et qu'apparemment c'est le jour du troll, je me demande s'il y a un anglophile qui va faire un 'report' de tout ces échanges pour nos amis anglophones ?
Et ben je peux même me dévouer, vu qu'en fin de compte, le résumé va être simple: tant du point de vue de l'"animation" de la discussion, du nombre de "pour" et du nombre de "contre" que des arguments employés, il se passe exactement la même chose sur f.c.l.py que sur c.l.py...
Le moins qu'on puisse dire est que ce PEP déchaîne les passions... -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
