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+-'])"
Justement, "internationale" ne veut pas dire "anglaise".
Mais la communauté internationale (à ton grand dam apparemment) a adopté l'Anglais
outils __gratuits__
"gratuits", ça veut dire "non payants" ? Comme Visual Studio Express (MS) ? Apollo (Adobe) ? Power-Shell (MS) ? Ponx (MCI) ?
Non, je faisait référence à FSF (et quelque chose me dit que tu le sais ;-) ) ... sans laquelle un ptit OS nommé Linux n'existerait pas.
Pour moi il n'y a pas d'intérêt à coder en Français puisque: 1) Le langage de programmation _est_ en Anglais (je vais pas lâcher le morceau) 2) mélanger deux langues dans du code c'est moche 3) du Français sans accent c'est _très_ moche 4) si le but des de rendre le code illisible aux étrangers, y'a qu'à pas leur donner 5) les spécs internationale (ISO, ANSI, CC, ....) sont en Anglais et que le code y fait référence 6) la prose informatique est bien plus riche en Anglais qu'en Français ... et qu'il faut la lire pour avancer (et devenir meilleur dans son travail) 7) la plupart des boîtes Françaises demandent des ingés qui parlent Anglais: s'entraîner à code en Français c'est se tirer dans le pied (si j'arrive un jour à rentrer chez moi et y démarrer une filiale ... et à embaucher, les malheureux gagnants ;-) devront être bilingues (au moins suffisement) pour adhérer aux critères ci-dessus) .
hg
MCI, Shadok Gouroudoudou wrote:
Salut !
communauté __internationale__
Justement, "internationale" ne veut pas dire "anglaise".
Mais la communauté internationale (à ton grand dam apparemment) a adopté
l'Anglais
outils __gratuits__
"gratuits", ça veut dire "non payants" ? Comme Visual Studio Express
(MS) ? Apollo (Adobe) ? Power-Shell (MS) ? Ponx (MCI) ?
Non, je faisait référence à FSF (et quelque chose me dit que tu le
sais ;-) ) ... sans laquelle un ptit OS nommé Linux n'existerait pas.
Pour moi il n'y a pas d'intérêt à coder en Français puisque:
1) Le langage de programmation _est_ en Anglais (je vais pas lâcher le
morceau)
2) mélanger deux langues dans du code c'est moche
3) du Français sans accent c'est _très_ moche
4) si le but des de rendre le code illisible aux étrangers, y'a qu'à pas
leur donner
5) les spécs internationale (ISO, ANSI, CC, ....) sont en Anglais et que le
code y fait référence
6) la prose informatique est bien plus riche en Anglais qu'en Français ...
et qu'il faut la lire pour avancer (et devenir meilleur dans son travail)
7) la plupart des boîtes Françaises demandent des ingés qui parlent Anglais:
s'entraîner à code en Français c'est se tirer dans le pied (si j'arrive un
jour à rentrer chez moi et y démarrer une filiale ... et à embaucher, les
malheureux gagnants ;-) devront être bilingues (au moins suffisement) pour
adhérer aux critères ci-dessus) .
Justement, "internationale" ne veut pas dire "anglaise".
Mais la communauté internationale (à ton grand dam apparemment) a adopté l'Anglais
outils __gratuits__
"gratuits", ça veut dire "non payants" ? Comme Visual Studio Express (MS) ? Apollo (Adobe) ? Power-Shell (MS) ? Ponx (MCI) ?
Non, je faisait référence à FSF (et quelque chose me dit que tu le sais ;-) ) ... sans laquelle un ptit OS nommé Linux n'existerait pas.
Pour moi il n'y a pas d'intérêt à coder en Français puisque: 1) Le langage de programmation _est_ en Anglais (je vais pas lâcher le morceau) 2) mélanger deux langues dans du code c'est moche 3) du Français sans accent c'est _très_ moche 4) si le but des de rendre le code illisible aux étrangers, y'a qu'à pas leur donner 5) les spécs internationale (ISO, ANSI, CC, ....) sont en Anglais et que le code y fait référence 6) la prose informatique est bien plus riche en Anglais qu'en Français ... et qu'il faut la lire pour avancer (et devenir meilleur dans son travail) 7) la plupart des boîtes Françaises demandent des ingés qui parlent Anglais: s'entraîner à code en Français c'est se tirer dans le pied (si j'arrive un jour à rentrer chez moi et y démarrer une filiale ... et à embaucher, les malheureux gagnants ;-) devront être bilingues (au moins suffisement) pour adhérer aux critères ci-dessus) .
hg
MCI, Shadok Gouroudoudou
Bonjour !
je connais même des dizaines de programmeurs qui causent anglais comme des vaches espagnoles, alors la valeur de l'anglais, c'est de la foutaise.
Vrai. Et, même parmi ceux qui maîtrisent l'anglais, beaucoup n'ont pas la même aisance qu'avec leur langue naturelle. D'où des difficultés de compréhension, ou d'expression, qui nuiront, ou dévaloriseront, leur compétences.
une longue expérience professionnelle m'a appris que s'embêter pour des futurs hypothétiques, neufs fois sur dix c'est s'embêter pour rien
+1. C'est incroyable, le nombre de choses qui ne se sont pas réalisées comme prévu. Je dirais même qu'intégrer cette notion constitue la plus grande part de toute expérience professionnelle.
passer à Windev
Petite explication perso : Je pense que, là, il s'agissait d'un clin d'oeil (provocateur) destiné spécifiquement à Bruno (mais je peux me tromper).
-- @-salutations
Michel Claveau
Bonjour !
je connais même des dizaines de programmeurs qui causent
anglais comme des vaches espagnoles, alors la valeur
de l'anglais, c'est de la foutaise.
Vrai. Et, même parmi ceux qui maîtrisent l'anglais, beaucoup n'ont pas
la même aisance qu'avec leur langue naturelle. D'où des difficultés de
compréhension, ou d'expression, qui nuiront, ou dévaloriseront, leur
compétences.
une longue expérience professionnelle m'a appris que s'embêter pour
des futurs hypothétiques, neufs fois sur dix c'est s'embêter pour rien
+1. C'est incroyable, le nombre de choses qui ne se sont pas réalisées
comme prévu. Je dirais même qu'intégrer cette notion constitue la plus
grande part de toute expérience professionnelle.
passer à Windev
Petite explication perso : Je pense que, là, il s'agissait d'un clin
d'oeil (provocateur) destiné spécifiquement à Bruno (mais je peux me
tromper).
je connais même des dizaines de programmeurs qui causent anglais comme des vaches espagnoles, alors la valeur de l'anglais, c'est de la foutaise.
Vrai. Et, même parmi ceux qui maîtrisent l'anglais, beaucoup n'ont pas la même aisance qu'avec leur langue naturelle. D'où des difficultés de compréhension, ou d'expression, qui nuiront, ou dévaloriseront, leur compétences.
une longue expérience professionnelle m'a appris que s'embêter pour des futurs hypothétiques, neufs fois sur dix c'est s'embêter pour rien
+1. C'est incroyable, le nombre de choses qui ne se sont pas réalisées comme prévu. Je dirais même qu'intégrer cette notion constitue la plus grande part de toute expérience professionnelle.
passer à Windev
Petite explication perso : Je pense que, là, il s'agissait d'un clin d'oeil (provocateur) destiné spécifiquement à Bruno (mais je peux me tromper).
-- @-salutations
Michel Claveau
MCI, Shadok Gouroudoudou
Salut !
communauté __internationale__
Justement, "internationale" ne veut pas dire "anglaise".
outils __gratuits__
"gratuits", ça veut dire "non payants" ? Comme Visual Studio Express (MS) ? Apollo (Adobe) ? Power-Shell (MS) ? Ponx (MCI) ?
-- @-salutations
Michel Claveau
Salut !
communauté __internationale__
Justement, "internationale" ne veut pas dire "anglaise".
outils __gratuits__
"gratuits", ça veut dire "non payants" ? Comme Visual Studio Express
(MS) ? Apollo (Adobe) ? Power-Shell (MS) ? Ponx (MCI) ?
Justement, "internationale" ne veut pas dire "anglaise".
outils __gratuits__
"gratuits", ça veut dire "non payants" ? Comme Visual Studio Express (MS) ? Apollo (Adobe) ? Power-Shell (MS) ? Ponx (MCI) ?
-- @-salutations
Michel Claveau
Pierre Hanser
vous êtes ahurissants: il y a la programmation de loisir non d'une pipe. il y a plein de non-informaticiens qui programment pour leurs loisirs! et d'informaticiens qui ne souhaitent pas programmer en petit-nègre.
C'est limite rasciste non ?
Non, c'est du français tout ce qu'il y a de plus officiel ;-)
merci j'ai eu un coup au coeur, ma main aurait elle dépassé ma pensée? vite le dictionnaire...
1er essai: Larousse compact 2001: *RIEN*
2eme essai: hachette 1980 (on prend ce qu'on a sous la main)
petit nègre: sabir à base de français utilisé par les communautés noires des anciennes colonies françaises, par extension, français incorrect, inintelligible, baragouin, charabia.
c'est pile ce que je voulais dire, mais pour faire plus moderne, je veux bien changer: 'français mâtiné de SMS'
-- Pierre
vous êtes ahurissants: il y a la programmation de loisir non
d'une pipe. il y a plein de non-informaticiens qui programment
pour leurs loisirs! et d'informaticiens qui ne souhaitent pas
programmer en petit-nègre.
C'est limite rasciste non ?
Non, c'est du français tout ce qu'il y a de plus officiel ;-)
merci
j'ai eu un coup au coeur, ma main aurait elle dépassé ma
pensée? vite le dictionnaire...
1er essai: Larousse compact 2001: *RIEN*
2eme essai: hachette 1980 (on prend ce qu'on a sous la main)
petit nègre: sabir à base de français utilisé par les
communautés noires des anciennes colonies françaises,
par extension, français incorrect, inintelligible,
baragouin, charabia.
c'est pile ce que je voulais dire, mais pour faire plus
moderne, je veux bien changer: 'français mâtiné de SMS'
vous êtes ahurissants: il y a la programmation de loisir non d'une pipe. il y a plein de non-informaticiens qui programment pour leurs loisirs! et d'informaticiens qui ne souhaitent pas programmer en petit-nègre.
C'est limite rasciste non ?
Non, c'est du français tout ce qu'il y a de plus officiel ;-)
merci j'ai eu un coup au coeur, ma main aurait elle dépassé ma pensée? vite le dictionnaire...
1er essai: Larousse compact 2001: *RIEN*
2eme essai: hachette 1980 (on prend ce qu'on a sous la main)
petit nègre: sabir à base de français utilisé par les communautés noires des anciennes colonies françaises, par extension, français incorrect, inintelligible, baragouin, charabia.
c'est pile ce que je voulais dire, mais pour faire plus moderne, je veux bien changer: 'français mâtiné de SMS'
-- Pierre
MCI, Shadok Gouroudoudou
Bonjour !
Pour ceux qui veuillent impérativement coder en Français; je leur conseille d'apprendre d'abord à coder un compilo ou un interpréteur
Erreur, on peut très bien ne pas connaître l'anglais, et programmer allègrement en Python, ou dans d'autres langages.
Pour programmer, il faut connaître (apprendre) les instructions, et diverses autres choses ; mais pas l'anglais (à condition d'avoir des docs, ou un tutorial, dans sa langue).
... de le faire en unicode
Unicode n'a rien à voir avec la langue. C'est juste un codage de caractères. Y compris certains caractères, ou symboles, qui ne sont utilisés dans aucune langue vivante (mais peuvent être utilisés par des anglophones). Juste un exemple : le symbole du diamètre.
-- @-salutations
Michel Claveau
Bonjour !
Pour ceux qui veuillent impérativement coder en Français; je leur
conseille d'apprendre d'abord à coder un compilo ou un interpréteur
Erreur, on peut très bien ne pas connaître l'anglais, et programmer
allègrement en Python, ou dans d'autres langages.
Pour programmer, il faut connaître (apprendre) les instructions, et
diverses autres choses ; mais pas l'anglais (à condition d'avoir des
docs, ou un tutorial, dans sa langue).
... de le faire en unicode
Unicode n'a rien à voir avec la langue. C'est juste un codage de
caractères. Y compris certains caractères, ou symboles, qui ne sont
utilisés dans aucune langue vivante (mais peuvent être utilisés par des
anglophones). Juste un exemple : le symbole du diamètre.
Pour ceux qui veuillent impérativement coder en Français; je leur conseille d'apprendre d'abord à coder un compilo ou un interpréteur
Erreur, on peut très bien ne pas connaître l'anglais, et programmer allègrement en Python, ou dans d'autres langages.
Pour programmer, il faut connaître (apprendre) les instructions, et diverses autres choses ; mais pas l'anglais (à condition d'avoir des docs, ou un tutorial, dans sa langue).
... de le faire en unicode
Unicode n'a rien à voir avec la langue. C'est juste un codage de caractères. Y compris certains caractères, ou symboles, qui ne sont utilisés dans aucune langue vivante (mais peuvent être utilisés par des anglophones). Juste un exemple : le symbole du diamètre.
-- @-salutations
Michel Claveau
William Dode
On 16-05-2007, MCI Shadok Gouroudoudou wrote:
Bonsoir !
Je ne connais pas de projet qui n'ait pas une chance de se retrouver un jour devant un programmeur non-francophone.
La plupart des programmes de gestion : payé, facturation, comptabilité, liasses fiscales, etc. Ces logiciels dépendent trop des lois et règlementations françaises pour aller à l'étranger.
Tu parles d'une portion du programme là, mais il sera sûrement composé d'un tas de portions qui peuvent elle être réutilisées dans un autre projet non francophone.
Et puis, il y a le cheminement inverse : des logiciels ou langages en anglais qui adoptent des mots-clefs français, pour pouvoir être diffusés en France. Par exemple VBA, qui est quand même un des langages informatique les plus répandus en France, bien que d'origine U.S., grâce à son adoptions des mots clefs français (entre autres).
Moi ce qui me gène le plus dans ce pep, ce n'est pas tant qu'on ne puisse pas se comprendre d'un développeur à l'autre, car c'est déjà le cas si on met des identifiants dans sa langue, même sans accent, mais plutôt le fait qu'on va avoir un tas de problèmes techniques à cause d'un éditeur de texte ou d'un outil quelconque qui buterait sur les accents... C'est pour ça que les trucs comme windev, vb ou autre n'ont pas ce genre de problème vu que l'éditeur fait partie intégrante du langage. Déjà qu'on se prend la tête quand on se retrouve en face d'un éditeur ne sachant pas gérer l'indentation, alors j'ose même pas imaginer un éditeur ne sachant pas gérer les accents ! Imaginons par ex d'être obligé de debuger un programme sur un serveur n'ayant pas les locales d'installées... Qui dit accent dit encoding, et regardez le nombre de posts sur les problèmes d'encoding !
-- William Dodé - http://flibuste.net Développeur informatique indépendant
On 16-05-2007, MCI Shadok Gouroudoudou wrote:
Bonsoir !
Je ne connais pas de projet qui n'ait pas une chance de se retrouver
un jour devant un programmeur non-francophone.
La plupart des programmes de gestion : payé, facturation, comptabilité,
liasses fiscales, etc. Ces logiciels dépendent trop des lois et
règlementations françaises pour aller à l'étranger.
Tu parles d'une portion du programme là, mais il sera sûrement composé
d'un tas de portions qui peuvent elle être réutilisées dans un autre
projet non francophone.
Et puis, il y a le cheminement inverse : des logiciels ou langages en
anglais qui adoptent des mots-clefs français, pour pouvoir être
diffusés en France. Par exemple VBA, qui est quand même un des langages
informatique les plus répandus en France, bien que d'origine U.S.,
grâce à son adoptions des mots clefs français (entre autres).
Moi ce qui me gène le plus dans ce pep, ce n'est pas tant qu'on ne
puisse pas se comprendre d'un développeur à l'autre, car c'est déjà le
cas si on met des identifiants dans sa langue, même sans accent, mais
plutôt le fait qu'on va avoir un tas de problèmes techniques à cause
d'un éditeur de texte ou d'un outil quelconque qui buterait sur les
accents... C'est pour ça que les trucs comme windev, vb ou autre n'ont
pas ce genre de problème vu que l'éditeur fait partie intégrante du
langage.
Déjà qu'on se prend la tête quand on se retrouve en face d'un éditeur ne
sachant pas gérer l'indentation, alors j'ose même pas imaginer un
éditeur ne sachant pas gérer les accents ! Imaginons par ex d'être
obligé de debuger un programme sur un serveur n'ayant pas les locales
d'installées...
Qui dit accent dit encoding, et regardez le nombre de posts sur les
problèmes d'encoding !
--
William Dodé - http://flibuste.net
Développeur informatique indépendant
Je ne connais pas de projet qui n'ait pas une chance de se retrouver un jour devant un programmeur non-francophone.
La plupart des programmes de gestion : payé, facturation, comptabilité, liasses fiscales, etc. Ces logiciels dépendent trop des lois et règlementations françaises pour aller à l'étranger.
Tu parles d'une portion du programme là, mais il sera sûrement composé d'un tas de portions qui peuvent elle être réutilisées dans un autre projet non francophone.
Et puis, il y a le cheminement inverse : des logiciels ou langages en anglais qui adoptent des mots-clefs français, pour pouvoir être diffusés en France. Par exemple VBA, qui est quand même un des langages informatique les plus répandus en France, bien que d'origine U.S., grâce à son adoptions des mots clefs français (entre autres).
Moi ce qui me gène le plus dans ce pep, ce n'est pas tant qu'on ne puisse pas se comprendre d'un développeur à l'autre, car c'est déjà le cas si on met des identifiants dans sa langue, même sans accent, mais plutôt le fait qu'on va avoir un tas de problèmes techniques à cause d'un éditeur de texte ou d'un outil quelconque qui buterait sur les accents... C'est pour ça que les trucs comme windev, vb ou autre n'ont pas ce genre de problème vu que l'éditeur fait partie intégrante du langage. Déjà qu'on se prend la tête quand on se retrouve en face d'un éditeur ne sachant pas gérer l'indentation, alors j'ose même pas imaginer un éditeur ne sachant pas gérer les accents ! Imaginons par ex d'être obligé de debuger un programme sur un serveur n'ayant pas les locales d'installées... Qui dit accent dit encoding, et regardez le nombre de posts sur les problèmes d'encoding !
-- William Dodé - http://flibuste.net Développeur informatique indépendant
MCI, Shadok Gouroudoudou
Re !
Rigolons un peu : Je préfère tout de même Transfert de Données Sociales.
Rigolons un peu plus : TDS, c'était tellement bien... qu'ils l'ont remplacé par la DADS... tout en maintenant une DADS-TDS
Ensuite, ils ont fait plusieurs versions de la DADS. Pour nommer ces versions, le terme DADS-U (DADS Unifiée) a été retenu. Alors, déjà que nous, pauvres développeurs français, on ne comprend pas bien le pourquoi du choix des termes, imaginon les étrangers...
D'ailleurs, j'ai le cas : un de mes clients a été racheté par des anglais. Qui se sont empressés d'imposer leurs logiciels (au détriment des miens).
Avant de réaliser que leu programme de paye n'était absolument pas adapté à la France. Donc, mon programme a été pérennisé.
Ensuite, les immobilisations ne sont pas gérés de la même façon, en Angleterre. Plutôt que de ne pas pouvoir générer les déclarations, ils ont préféré garder mon logiciel.
Concernant la comptabilité analytique, les comptas anglo-saxonnes fonctionnent très différement. Du coup, ils hésitent à utiliser leur compta, ce qui faciliterait le reporting financier, mais ils perdraient alors beaucoup de fonctionnalités.
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.
-- @-salutations
Michel Claveau
Re !
Rigolons un peu : Je préfère tout de même Transfert de Données Sociales.
Rigolons un peu plus : TDS, c'était tellement bien... qu'ils l'ont
remplacé par la DADS... tout en maintenant une DADS-TDS
Ensuite, ils ont fait plusieurs versions de la DADS. Pour nommer ces
versions, le terme DADS-U (DADS Unifiée) a été retenu.
Alors, déjà que nous, pauvres développeurs français, on ne comprend pas
bien le pourquoi du choix des termes, imaginon les étrangers...
D'ailleurs, j'ai le cas : un de mes clients a été racheté par des
anglais. Qui se sont empressés d'imposer leurs logiciels (au détriment
des miens).
Avant de réaliser que leu programme de paye n'était absolument pas
adapté à la France. Donc, mon programme a été pérennisé.
Ensuite, les immobilisations ne sont pas gérés de la même façon, en
Angleterre. Plutôt que de ne pas pouvoir générer les déclarations, ils
ont préféré garder mon logiciel.
Concernant la comptabilité analytique, les comptas anglo-saxonnes
fonctionnent très différement. Du coup, ils hésitent à utiliser leur
compta, ce qui faciliterait le reporting financier, mais ils perdraient
alors beaucoup de fonctionnalités.
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.
Rigolons un peu : Je préfère tout de même Transfert de Données Sociales.
Rigolons un peu plus : TDS, c'était tellement bien... qu'ils l'ont remplacé par la DADS... tout en maintenant une DADS-TDS
Ensuite, ils ont fait plusieurs versions de la DADS. Pour nommer ces versions, le terme DADS-U (DADS Unifiée) a été retenu. Alors, déjà que nous, pauvres développeurs français, on ne comprend pas bien le pourquoi du choix des termes, imaginon les étrangers...
D'ailleurs, j'ai le cas : un de mes clients a été racheté par des anglais. Qui se sont empressés d'imposer leurs logiciels (au détriment des miens).
Avant de réaliser que leu programme de paye n'était absolument pas adapté à la France. Donc, mon programme a été pérennisé.
Ensuite, les immobilisations ne sont pas gérés de la même façon, en Angleterre. Plutôt que de ne pas pouvoir générer les déclarations, ils ont préféré garder mon logiciel.
Concernant la comptabilité analytique, les comptas anglo-saxonnes fonctionnent très différement. Du coup, ils hésitent à utiliser leur compta, ce qui faciliterait le reporting financier, mais ils perdraient alors beaucoup de fonctionnalités.
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.
-- @-salutations
Michel Claveau
MCI, Shadok Gouroudoudou
'français mâtiné de SMS'
Bigre ! Quel langage châtié ! Digne d'un preux défenseur de la langue de Molière.
-- @-salutations
Michel Claveau
'français mâtiné de SMS'
Bigre ! Quel langage châtié !
Digne d'un preux défenseur de la langue de Molière.
Bigre ! Quel langage châtié ! Digne d'un preux défenseur de la langue de Molière.
-- @-salutations
Michel Claveau
Encolpe Degoute
Bonjour !
Pour ceux qui veuillent impérativement coder en Français; je leur conseille d'apprendre d'abord à coder un compilo ou un interpréteur
Erreur, on peut très bien ne pas connaître l'anglais, et programmer allègrement en Python, ou dans d'autres langages.
Pourquoi commencer votre phrase par 'Erreur'. Il ne vous dit pas qu'il faille programmer en anglais, il vous dit d'essayer d'écrire un compilateur ou un interpréteur basé sur votre langue naturelle.
Pour programmer, il faut connaître (apprendre) les instructions, et diverses autres choses ; mais pas l'anglais (à condition d'avoir des docs, ou un tutorial, dans sa langue).
Ah, c'est vous le créateur du Logo ? http://fr.wikipedia.org/wiki/Logo_(langage)
<span mode="troll"> C'est bizarre, même si les variables sont en français il n'y a pas d'accents. </span>
... de le faire en unicode
Unicode n'a rien à voir avec la langue. C'est juste un codage de caractères. Y compris certains caractères, ou symboles, qui ne sont utilisés dans aucune langue vivante (mais peuvent être utilisés par des anglophones). Juste un exemple : le symbole du diamètre.
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 identifiants cela veut dire que l'analyse sera d'autant plus longue. Ensuite vous aurez le problème des homonymes entre plusieurs langues, celui des caractères qui prennent un sens différents selon la langue et celui des symboles mathématiques. Au fait, comment écrivez-vous: « quinze mille virgule zéro trois fois 2 divisé par 3 »
15000.03 * 3 / 2 ou 15.000,03 × 3 ÷ 2
Vous voulez militer pour quelque que chose d'amusant, militez pour le passage du protocole NNTP en IPv6 ou pour que ce forum accepte l'utf-8.
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
Bonjour !
Pour ceux qui veuillent impérativement coder en Français; je leur
conseille d'apprendre d'abord à coder un compilo ou un interpréteur
Erreur, on peut très bien ne pas connaître l'anglais, et programmer
allègrement en Python, ou dans d'autres langages.
Pourquoi commencer votre phrase par 'Erreur'. Il ne vous dit pas qu'il
faille programmer en anglais, il vous dit d'essayer d'écrire un
compilateur ou un interpréteur basé sur votre langue naturelle.
Pour programmer, il faut connaître (apprendre) les instructions, et
diverses autres choses ; mais pas l'anglais (à condition d'avoir des
docs, ou un tutorial, dans sa langue).
Ah, c'est vous le créateur du Logo ?
http://fr.wikipedia.org/wiki/Logo_(langage)
<span mode="troll">
C'est bizarre, même si les variables sont en français il n'y a pas
d'accents.
</span>
... de le faire en unicode
Unicode n'a rien à voir avec la langue. C'est juste un codage de
caractères. Y compris certains caractères, ou symboles, qui ne sont
utilisés dans aucune langue vivante (mais peuvent être utilisés par des
anglophones). Juste un exemple : le symbole du diamètre.
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
identifiants cela veut dire que l'analyse sera d'autant plus longue.
Ensuite vous aurez le problème des homonymes entre plusieurs langues,
celui des caractères qui prennent un sens différents selon la langue et
celui des symboles mathématiques. Au fait, comment écrivez-vous:
« quinze mille virgule zéro trois fois 2 divisé par 3 »
15000.03 * 3 / 2 ou 15.000,03 × 3 ÷ 2
Vous voulez militer pour quelque que chose d'amusant, militez pour le
passage du protocole NNTP en IPv6 ou pour que ce forum accepte l'utf-8.
--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales
Pour ceux qui veuillent impérativement coder en Français; je leur conseille d'apprendre d'abord à coder un compilo ou un interpréteur
Erreur, on peut très bien ne pas connaître l'anglais, et programmer allègrement en Python, ou dans d'autres langages.
Pourquoi commencer votre phrase par 'Erreur'. Il ne vous dit pas qu'il faille programmer en anglais, il vous dit d'essayer d'écrire un compilateur ou un interpréteur basé sur votre langue naturelle.
Pour programmer, il faut connaître (apprendre) les instructions, et diverses autres choses ; mais pas l'anglais (à condition d'avoir des docs, ou un tutorial, dans sa langue).
Ah, c'est vous le créateur du Logo ? http://fr.wikipedia.org/wiki/Logo_(langage)
<span mode="troll"> C'est bizarre, même si les variables sont en français il n'y a pas d'accents. </span>
... de le faire en unicode
Unicode n'a rien à voir avec la langue. C'est juste un codage de caractères. Y compris certains caractères, ou symboles, qui ne sont utilisés dans aucune langue vivante (mais peuvent être utilisés par des anglophones). Juste un exemple : le symbole du diamètre.
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 identifiants cela veut dire que l'analyse sera d'autant plus longue. Ensuite vous aurez le problème des homonymes entre plusieurs langues, celui des caractères qui prennent un sens différents selon la langue et celui des symboles mathématiques. Au fait, comment écrivez-vous: « quinze mille virgule zéro trois fois 2 divisé par 3 »
15000.03 * 3 / 2 ou 15.000,03 × 3 ÷ 2
Vous voulez militer pour quelque que chose d'amusant, militez pour le passage du protocole NNTP en IPv6 ou pour que ce forum accepte l'utf-8.
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
Christophe Cavalaria
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.
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. 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)
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é.
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.
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.
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)
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é.
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.
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. 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)
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é.
