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+-'])"
On Fri, 18 May 2007 09:09:03 +0200, Eric Brunel wrote:
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...
... sauf que la discussion est en train de mourir sur c.l.py, et que de toutes façons, le PEP a été accepté: http://www.python.org/dev/peps/pep-3131/
Bon. Attendons que la possibilité soit utilisée; il sera toujours temps de recommencer à hurler pour avoir une option --ascii-only dans l'interpréteur si ça dégénère (ou quand ça dégénèrera, mais on ne va pas s'y remettre...). -- 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 09:09:03 +0200, Eric Brunel <see.signature@no.spam>
wrote:
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...
... sauf que la discussion est en train de mourir sur c.l.py, et que de
toutes façons, le PEP a été accepté:
http://www.python.org/dev/peps/pep-3131/
Bon. Attendons que la possibilité soit utilisée; il sera toujours temps de
recommencer à hurler pour avoir une option --ascii-only dans
l'interpréteur si ça dégénère (ou quand ça dégénèrera, mais on ne va pas
s'y remettre...).
--
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 09:09:03 +0200, Eric Brunel wrote:
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...
... sauf que la discussion est en train de mourir sur c.l.py, et que de toutes façons, le PEP a été accepté: http://www.python.org/dev/peps/pep-3131/
Bon. Attendons que la possibilité soit utilisée; il sera toujours temps de recommencer à hurler pour avoir une option --ascii-only dans l'interpréteur si ça dégénère (ou quand ça dégénèrera, mais on ne va pas s'y remettre...). -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Laurent Pointal
Eric Brunel wrote:
Le moins qu'on puisse dire est que ce PEP déchaîne les passions...
Oui, mais c'est intéressant cette confrontation des points de vue.
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:
* pour les personnes qui ne sont pas des experts en développement (amateurs, ou dans le cadre d'enseignements), afin de pouvoir utiliser des noms qui ont un sens pour eux, et pour les développeurs qui veulent donner un sens "métier" clair à leurs identificateurs - surtout pour les langues qui ne sont pas basés sur les caractères latins où le problème doit être exacerbé. Ils peuvent en effet déjà utiliser unicode dans les chaînes (documentations comprise).
* pour des échanges avec des langages informatiques qui autorisent de tels identificateurs... et pour lesquels c'est utilisé (je met le binding des noms de table/colonne dans les SGBDR dans ce cadre).
* (non exprimé tel quel) ça permettra de "verrouiller" un peu le code et éviter qu'il puisse être repris/délocalisé n'importe où par n'importe qui - je pense que pour certains cet aspect n'est pas négligeable.
Dans les discussions j'ai pu voir que le problème du mélange de certains caractères qui ont différentes entrées dans la table unicode pour le même rendu (ex. le oméga) ne se pose pas (pour les identificateurs, utilisation de je ne sais plus quel attribut unicode liée à l'aspect graphique du caractère).
L'aspect perte de vitesse mériterais d'être vérifié, je ne suis pas sûr qu'on perde tant que ça.
Côté édition, on a quand même ce qu'il faut pour éditer des fichiers unicode (d'ailleurs je configure maintenant mes éditeurs sous Windows ou Linux pour qu'ils enregistrent en utf-8).
Je rejoins les inquiétudes sur la capacité à relire le code d'un projet qui utiliserais de tels identificateurs... (je ne lis ni le cyrillique, ni le kanji, ni le hindi) mais bon, ça serait laisser la liberté aux utilisateurs.
Ca peut/pourrais m'emmerder dans certains cas, mais est-ce une raison pour que je l'interdise à d'autres qui en ressentent le besoin?
Ce qu'il faudrais si ce PEP passe, AMA:
* un re-travail sur les traceback afin d'avoir une option générale, genre -T, pour s'assurer que les traces d'exceptions ne produisent QUE de l'ascii, pour éviter les problèmes d'affichage des erreurs.
* une possibilité d'indiquer pour des modules qu'ils ne doivent *définir* que des noms utilisant l'ascii, du genre from __futur__ import asciionly
* et bien sûr que les librairies standard Python limitent les identificateurs qu'elles définissent en ascii seul (plus petit commun dénominateur).
Eric Brunel wrote:
Le moins qu'on puisse dire est que ce PEP déchaîne les passions...
Oui, mais c'est intéressant cette confrontation des points de vue.
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:
* pour les personnes qui ne sont pas des experts en développement (amateurs,
ou dans le cadre d'enseignements), afin de pouvoir utiliser des noms qui
ont un sens pour eux, et pour les développeurs qui veulent donner un
sens "métier" clair à leurs identificateurs - surtout pour les langues qui
ne sont pas basés sur les caractères latins où le problème doit être
exacerbé.
Ils peuvent en effet déjà utiliser unicode dans les chaînes (documentations
comprise).
* pour des échanges avec des langages informatiques qui autorisent de tels
identificateurs... et pour lesquels c'est utilisé (je met le binding des
noms de table/colonne dans les SGBDR dans ce cadre).
* (non exprimé tel quel) ça permettra de "verrouiller" un peu le code et
éviter qu'il puisse être repris/délocalisé n'importe où par n'importe qui -
je pense que pour certains cet aspect n'est pas négligeable.
Dans les discussions j'ai pu voir que le problème du mélange de certains
caractères qui ont différentes entrées dans la table unicode pour le même
rendu (ex. le oméga) ne se pose pas (pour les identificateurs, utilisation
de je ne sais plus quel attribut unicode liée à l'aspect graphique du
caractère).
L'aspect perte de vitesse mériterais d'être vérifié, je ne suis pas sûr
qu'on perde tant que ça.
Côté édition, on a quand même ce qu'il faut pour éditer des fichiers unicode
(d'ailleurs je configure maintenant mes éditeurs sous Windows ou Linux pour
qu'ils enregistrent en utf-8).
Je rejoins les inquiétudes sur la capacité à relire le code d'un projet qui
utiliserais de tels identificateurs... (je ne lis ni le cyrillique, ni le
kanji, ni le hindi) mais bon, ça serait laisser la liberté aux
utilisateurs.
Ca peut/pourrais m'emmerder dans certains cas, mais est-ce une raison pour
que je l'interdise à d'autres qui en ressentent le besoin?
Ce qu'il faudrais si ce PEP passe, AMA:
* un re-travail sur les traceback afin d'avoir une option générale,
genre -T, pour s'assurer que les traces d'exceptions ne produisent QUE de
l'ascii, pour éviter les problèmes d'affichage des erreurs.
* une possibilité d'indiquer pour des modules qu'ils ne doivent *définir*
que des noms utilisant l'ascii, du genre from __futur__ import asciionly
* et bien sûr que les librairies standard Python limitent les
identificateurs qu'elles définissent en ascii seul (plus petit commun
dénominateur).
Le moins qu'on puisse dire est que ce PEP déchaîne les passions...
Oui, mais c'est intéressant cette confrontation des points de vue.
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:
* pour les personnes qui ne sont pas des experts en développement (amateurs, ou dans le cadre d'enseignements), afin de pouvoir utiliser des noms qui ont un sens pour eux, et pour les développeurs qui veulent donner un sens "métier" clair à leurs identificateurs - surtout pour les langues qui ne sont pas basés sur les caractères latins où le problème doit être exacerbé. Ils peuvent en effet déjà utiliser unicode dans les chaînes (documentations comprise).
* pour des échanges avec des langages informatiques qui autorisent de tels identificateurs... et pour lesquels c'est utilisé (je met le binding des noms de table/colonne dans les SGBDR dans ce cadre).
* (non exprimé tel quel) ça permettra de "verrouiller" un peu le code et éviter qu'il puisse être repris/délocalisé n'importe où par n'importe qui - je pense que pour certains cet aspect n'est pas négligeable.
Dans les discussions j'ai pu voir que le problème du mélange de certains caractères qui ont différentes entrées dans la table unicode pour le même rendu (ex. le oméga) ne se pose pas (pour les identificateurs, utilisation de je ne sais plus quel attribut unicode liée à l'aspect graphique du caractère).
L'aspect perte de vitesse mériterais d'être vérifié, je ne suis pas sûr qu'on perde tant que ça.
Côté édition, on a quand même ce qu'il faut pour éditer des fichiers unicode (d'ailleurs je configure maintenant mes éditeurs sous Windows ou Linux pour qu'ils enregistrent en utf-8).
Je rejoins les inquiétudes sur la capacité à relire le code d'un projet qui utiliserais de tels identificateurs... (je ne lis ni le cyrillique, ni le kanji, ni le hindi) mais bon, ça serait laisser la liberté aux utilisateurs.
Ca peut/pourrais m'emmerder dans certains cas, mais est-ce une raison pour que je l'interdise à d'autres qui en ressentent le besoin?
Ce qu'il faudrais si ce PEP passe, AMA:
* un re-travail sur les traceback afin d'avoir une option générale, genre -T, pour s'assurer que les traces d'exceptions ne produisent QUE de l'ascii, pour éviter les problèmes d'affichage des erreurs.
* une possibilité d'indiquer pour des modules qu'ils ne doivent *définir* que des noms utilisant l'ascii, du genre from __futur__ import asciionly
* et bien sûr que les librairies standard Python limitent les identificateurs qu'elles définissent en ascii seul (plus petit commun dénominateur).
MCI, Shadok Gouroudoudou
Bonjour !
Pour les éditeurs qui ne gèreraient pas les accents, il y a une solution simple.
Il suffit de traiter ces cas exactement comme s'y prend PyYaml lorsqu'il rencontre une clef contenant de l'unicode.
Ou alors, faire comme Javascript : les caractères <256 (ou latin-1 ou 15, je ne sais plus) sont traités directement, les autres sont notitfiés en unicode : var mau0438var = new Object()
-- @-salutations
Michel Claveau
Bonjour !
Pour les éditeurs qui ne gèreraient pas les accents, il y a une
solution simple.
Il suffit de traiter ces cas exactement comme s'y prend PyYaml
lorsqu'il rencontre une clef contenant de l'unicode.
Ou alors, faire comme Javascript : les caractères <256 (ou latin-1 ou
15, je ne sais plus) sont traités directement, les autres sont
notitfiés en unicode :
var mau0438var = new Object()
Pour les éditeurs qui ne gèreraient pas les accents, il y a une solution simple.
Il suffit de traiter ces cas exactement comme s'y prend PyYaml lorsqu'il rencontre une clef contenant de l'unicode.
Ou alors, faire comme Javascript : les caractères <256 (ou latin-1 ou 15, je ne sais plus) sont traités directement, les autres sont notitfiés en unicode : var mau0438var = new Object()
-- @-salutations
Michel Claveau
MCI, Shadok Gouroudoudou
Salut !
je ne serais pas aussi optimiste
Attention : je pense que techniquement, nous sommes très bien placés. Malheureusement, on se fait avoir sur des aspects non techniques (démarche commerciale, stratégique, d'autorité, etc.)
La plupart des grands logiciels sont imposés sur des critères non techniques.
Je ne compte plus le nombre de cas que j'ai vécus. Voici qq réflexions récoltées : - c'est le siège qui décide - à ce niveau de prix, les éditeurs ne peuvent pas se permettre de diffuser un logiciel qui ne fonctionnera pas ; donc, inutile de comparer techniquement, mais attardons-nous sur les aspects financiers - un logiciel, c'est un outil, comme nos autres machines. On travaillera avec celui qu'on nous installe, qu'il soit bien ou non. - si on perd en fonctionnalités, et que l'entreprise survit, c'est que ces fonctionnalités étaient inutiles. - on ne pourra plus faire ça ? Tant mieux, on aura du temps pour autre chose.
Comme les décideurs ont très souvent de faibles compétences en informatique, les points de vue techniques leur échappe. Et cette réflexion peut s'étendre aux autres moyens de production. Malheureusement.
-- @-salutations
Michel Claveau
Salut !
je ne serais pas aussi optimiste
Attention : je pense que techniquement, nous sommes très bien placés.
Malheureusement, on se fait avoir sur des aspects non techniques
(démarche commerciale, stratégique, d'autorité, etc.)
La plupart des grands logiciels sont imposés sur des critères non
techniques.
Je ne compte plus le nombre de cas que j'ai vécus.
Voici qq réflexions récoltées :
- c'est le siège qui décide
- à ce niveau de prix, les éditeurs ne peuvent pas se permettre de
diffuser un logiciel qui ne fonctionnera pas ; donc, inutile de
comparer techniquement, mais attardons-nous sur les aspects financiers
- un logiciel, c'est un outil, comme nos autres machines. On
travaillera avec celui qu'on nous installe, qu'il soit bien ou non.
- si on perd en fonctionnalités, et que l'entreprise survit, c'est
que ces fonctionnalités étaient inutiles.
- on ne pourra plus faire ça ? Tant mieux, on aura du temps pour
autre chose.
Comme les décideurs ont très souvent de faibles compétences en
informatique, les points de vue techniques leur échappe. Et cette
réflexion peut s'étendre aux autres moyens de production.
Malheureusement.
Attention : je pense que techniquement, nous sommes très bien placés. Malheureusement, on se fait avoir sur des aspects non techniques (démarche commerciale, stratégique, d'autorité, etc.)
La plupart des grands logiciels sont imposés sur des critères non techniques.
Je ne compte plus le nombre de cas que j'ai vécus. Voici qq réflexions récoltées : - c'est le siège qui décide - à ce niveau de prix, les éditeurs ne peuvent pas se permettre de diffuser un logiciel qui ne fonctionnera pas ; donc, inutile de comparer techniquement, mais attardons-nous sur les aspects financiers - un logiciel, c'est un outil, comme nos autres machines. On travaillera avec celui qu'on nous installe, qu'il soit bien ou non. - si on perd en fonctionnalités, et que l'entreprise survit, c'est que ces fonctionnalités étaient inutiles. - on ne pourra plus faire ça ? Tant mieux, on aura du temps pour autre chose.
Comme les décideurs ont très souvent de faibles compétences en informatique, les points de vue techniques leur échappe. Et cette réflexion peut s'étendre aux autres moyens de production. Malheureusement.
-- @-salutations
Michel Claveau
MCI, Shadok Gouroudoudou
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
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 ? "
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
MCI, Shadok Gouroudoudou
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
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
MCI, Shadok Gouroudoudou
Bonjour !
le PEP a été accepté
Toi qui parles étranger, pourrais-tu nous résumer, pour savoir "pour quand ce sera ?"
Parce que, en pratique, j'ai déjà bloqué le développement d'un wrapper du BDE, pour les questions de connexion à des champs avec noms accentués, dans des bases de données déjà existantes.
La date de sortie prévue va fortement influencer sur le développement de cet outil.
Merci d'avance.
-- @-salutations
Michel Claveau
Bonjour !
le PEP a été accepté
Toi qui parles étranger, pourrais-tu nous résumer, pour savoir "pour
quand ce sera ?"
Parce que, en pratique, j'ai déjà bloqué le développement d'un wrapper
du BDE, pour les questions de connexion à des champs avec noms
accentués, dans des bases de données déjà existantes.
La date de sortie prévue va fortement influencer sur le développement
de cet outil.
Toi qui parles étranger, pourrais-tu nous résumer, pour savoir "pour quand ce sera ?"
Parce que, en pratique, j'ai déjà bloqué le développement d'un wrapper du BDE, pour les questions de connexion à des champs avec noms accentués, dans des bases de données déjà existantes.
La date de sortie prévue va fortement influencer sur le développement de cet outil.
Merci d'avance.
-- @-salutations
Michel Claveau
Christophe Cavalaria
MCI, Shadok Gouroudoudou wrote:
Bonjour !
le PEP a été accepté
Toi qui parles étranger, pourrais-tu nous résumer, pour savoir "pour quand ce sera ?"
Parce que, en pratique, j'ai déjà bloqué le développement d'un wrapper du BDE, pour les questions de connexion à des champs avec noms accentués, dans des bases de données déjà existantes.
La date de sortie prévue va fortement influencer sur le développement de cet outil.
C'est marqué dans le PEP il me semble. C'est une feature pour Python 3(000)
MCI, Shadok Gouroudoudou wrote:
Bonjour !
le PEP a été accepté
Toi qui parles étranger, pourrais-tu nous résumer, pour savoir "pour
quand ce sera ?"
Parce que, en pratique, j'ai déjà bloqué le développement d'un wrapper
du BDE, pour les questions de connexion à des champs avec noms
accentués, dans des bases de données déjà existantes.
La date de sortie prévue va fortement influencer sur le développement
de cet outil.
C'est marqué dans le PEP il me semble. C'est une feature pour Python 3(000)
Toi qui parles étranger, pourrais-tu nous résumer, pour savoir "pour quand ce sera ?"
Parce que, en pratique, j'ai déjà bloqué le développement d'un wrapper du BDE, pour les questions de connexion à des champs avec noms accentués, dans des bases de données déjà existantes.
La date de sortie prévue va fortement influencer sur le développement de cet outil.
C'est marqué dans le PEP il me semble. C'est une feature pour Python 3(000)
Pierre Hanser
Bonjour !
le PEP a été accepté
Toi qui parles étranger, pourrais-tu nous résumer, pour savoir "pour quand ce sera ?"
si j'ai bien suivi, c'est un projet pour python3000 personne ne s'est engagé sur le report dans une version actuelle.
maintenant quand sort python3000? en fouillant un peu j'ai retrouvé ceci: version alpha en juin 2007 version finale moins d'un an après (sic) -- Pierre
Bonjour !
le PEP a été accepté
Toi qui parles étranger, pourrais-tu nous résumer, pour savoir "pour
quand ce sera ?"
si j'ai bien suivi, c'est un projet pour python3000
personne ne s'est engagé sur le report dans une version
actuelle.
maintenant quand sort python3000?
en fouillant un peu j'ai retrouvé ceci: version alpha en juin 2007
version finale moins d'un an après (sic)
--
Pierre
Toi qui parles étranger, pourrais-tu nous résumer, pour savoir "pour quand ce sera ?"
si j'ai bien suivi, c'est un projet pour python3000 personne ne s'est engagé sur le report dans une version actuelle.
maintenant quand sort python3000? en fouillant un peu j'ai retrouvé ceci: version alpha en juin 2007 version finale moins d'un an après (sic) -- Pierre
MCI, Shadok Gouroudoudou
Bonjour !
C'est marqué dans le PEP il me semble. C'est une feature pour Python 3
Merci de l'info.
Car : - moi et l'anglais, ça provoque des problèmes de compréhension - Aîe ! Python 3(000), c'est un truc hypotétique que ne sortira sans doute jamais. - il me semblait que certains utilisait l'expression "Python 3" pour traiter des aspects qui étaient souvent implémentés dans les versions suivantes. Cela pourrait-il être le cas, avec le PEP-3131 & Python 2.6 ? - c'est quoi, une "féature" ?
-- @-salutations
Michel Claveau
Bonjour !
C'est marqué dans le PEP il me semble. C'est une feature pour Python 3
Merci de l'info.
Car :
- moi et l'anglais, ça provoque des problèmes de compréhension
- Aîe ! Python 3(000), c'est un truc hypotétique que ne sortira sans
doute jamais.
- il me semblait que certains utilisait l'expression "Python 3" pour
traiter des aspects qui étaient souvent implémentés dans les versions
suivantes. Cela pourrait-il être le cas, avec le PEP-3131 & Python 2.6
?
- c'est quoi, une "féature" ?
C'est marqué dans le PEP il me semble. C'est une feature pour Python 3
Merci de l'info.
Car : - moi et l'anglais, ça provoque des problèmes de compréhension - Aîe ! Python 3(000), c'est un truc hypotétique que ne sortira sans doute jamais. - il me semblait que certains utilisait l'expression "Python 3" pour traiter des aspects qui étaient souvent implémentés dans les versions suivantes. Cela pourrait-il être le cas, avec le PEP-3131 & Python 2.6 ? - c'est quoi, une "féature" ?
