Sur le PEP suivant, on trouve des indications sur les orientations futures
de Python. Ce qui est le plus intéressant, AMHA, pour éviter d'utiliser des
choses qui seront supprimées dans l'avenir.
L'URL : http://www.python.org/peps/pep-3000.html
J'ai noté un point qui m'avait échappé : la condamnation, à moyen terme, de
xrange (il est conseillé d'utiliser range).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
tiissa
Do Re Mi chel La Si Do wrote:
Bonjour !
Sur le PEP suivant, on trouve des indications sur les orientations futures de Python. Ce qui est le plus intéressant, AMHA, pour éviter d'utiliser des choses qui seront supprimées dans l'avenir.
L'URL : http://www.python.org/peps/pep-3000.html
J'ai noté un point qui m'avait échappé : la condamnation, à moyen terme, de xrange (il est conseillé d'utiliser range).
En effet. Et, juste au dessus, il est marqué que les built-ins tels que range() et zip() retourneraient des itérateurs. Du coup, c'est plutôt range() qui disparaît au profit d'un xrange() renommé.
Do Re Mi chel La Si Do wrote:
Bonjour !
Sur le PEP suivant, on trouve des indications sur les orientations futures
de Python. Ce qui est le plus intéressant, AMHA, pour éviter d'utiliser des
choses qui seront supprimées dans l'avenir.
L'URL : http://www.python.org/peps/pep-3000.html
J'ai noté un point qui m'avait échappé : la condamnation, à moyen terme, de
xrange (il est conseillé d'utiliser range).
En effet. Et, juste au dessus, il est marqué que les built-ins tels que
range() et zip() retourneraient des itérateurs.
Du coup, c'est plutôt range() qui disparaît au profit d'un xrange() renommé.
Sur le PEP suivant, on trouve des indications sur les orientations futures de Python. Ce qui est le plus intéressant, AMHA, pour éviter d'utiliser des choses qui seront supprimées dans l'avenir.
L'URL : http://www.python.org/peps/pep-3000.html
J'ai noté un point qui m'avait échappé : la condamnation, à moyen terme, de xrange (il est conseillé d'utiliser range).
En effet. Et, juste au dessus, il est marqué que les built-ins tels que range() et zip() retourneraient des itérateurs. Du coup, c'est plutôt range() qui disparaît au profit d'un xrange() renommé.
Do Re Mi chel La Si Do
Re
c'est plutôt range() qui disparaît au profit d'un xrange() renommé
Certes, mais il reste qu'il vaut mieux éviter d'utiliser la syntaxe "xrange" dans nos logiciels.
@-salutations -- Michel Claveau
Re
c'est plutôt range() qui disparaît au profit d'un xrange() renommé
Certes, mais il reste qu'il vaut mieux éviter d'utiliser la syntaxe "xrange"
dans nos logiciels.
c'est plutôt range() qui disparaît au profit d'un xrange() renommé
Certes, mais il reste qu'il vaut mieux éviter d'utiliser la syntaxe "xrange" dans nos logiciels.
@-salutations -- Michel Claveau
tiissa
Do Re Mi chel La Si Do wrote:
c'est plutôt range() qui disparaît au profit d'un xrange() renommé
Certes, mais il reste qu'il vaut mieux éviter d'utiliser la syntaxe "xrange" dans nos logiciels.
Je ne pense pas.
Python 3000 semble être prévu pour corriger (entre autres) des erreurs de conception sans se soucier de la compatibilité ascendante. Cela signifie en particulier que nos programmes actuels risquent fort de ne pas fonctionner sans adaptation. Et changer 'xrange()' en 'range()' dans notre code n'en sera probablement pas la plus lourde. ;)
Mais il faut bien voir qu'il ne s'agit pour l'instant que d'un projet à long terme, contrairement aux versions 2.5 et éventuellement 2.x suivantes qui elles garderont autant que possible la compatibilité avec la base de programmes existante.
Il ne me paraît pas vraiment judicieux de perdre de la performance actuellement en utilisant 'range()' à la place des appels à de gros 'xrange()' juste pour s'habituer à un langage hypothétique avec des spécifications aucunement figées.
A mon humble avis, on aura le temps de voir python 3000 arriver et ce n'est pas ce style de détails qui doit monopoliser notre attention.
A noter que la future suppression des lambda, map, filter et autres reduce génère actuellement beaucoup de traffic sur comp.lang.python et ça risque d'être le cas pendant encore longtemps. Rien que ces changements-ci demanderont sans doute plus d'effort que la perte d'xrange.
Do Re Mi chel La Si Do wrote:
c'est plutôt range() qui disparaît au profit d'un xrange() renommé
Certes, mais il reste qu'il vaut mieux éviter d'utiliser la syntaxe "xrange"
dans nos logiciels.
Je ne pense pas.
Python 3000 semble être prévu pour corriger (entre autres) des erreurs
de conception sans se soucier de la compatibilité ascendante. Cela
signifie en particulier que nos programmes actuels risquent fort de ne
pas fonctionner sans adaptation.
Et changer 'xrange()' en 'range()' dans notre code n'en sera
probablement pas la plus lourde. ;)
Mais il faut bien voir qu'il ne s'agit pour l'instant que d'un projet à
long terme, contrairement aux versions 2.5 et éventuellement 2.x
suivantes qui elles garderont autant que possible la compatibilité avec
la base de programmes existante.
Il ne me paraît pas vraiment judicieux de perdre de la performance
actuellement en utilisant 'range()' à la place des appels à de gros
'xrange()' juste pour s'habituer à un langage hypothétique avec des
spécifications aucunement figées.
A mon humble avis, on aura le temps de voir python 3000 arriver et ce
n'est pas ce style de détails qui doit monopoliser notre attention.
A noter que la future suppression des lambda, map, filter et autres
reduce génère actuellement beaucoup de traffic sur comp.lang.python et
ça risque d'être le cas pendant encore longtemps. Rien que ces
changements-ci demanderont sans doute plus d'effort que la perte d'xrange.
c'est plutôt range() qui disparaît au profit d'un xrange() renommé
Certes, mais il reste qu'il vaut mieux éviter d'utiliser la syntaxe "xrange" dans nos logiciels.
Je ne pense pas.
Python 3000 semble être prévu pour corriger (entre autres) des erreurs de conception sans se soucier de la compatibilité ascendante. Cela signifie en particulier que nos programmes actuels risquent fort de ne pas fonctionner sans adaptation. Et changer 'xrange()' en 'range()' dans notre code n'en sera probablement pas la plus lourde. ;)
Mais il faut bien voir qu'il ne s'agit pour l'instant que d'un projet à long terme, contrairement aux versions 2.5 et éventuellement 2.x suivantes qui elles garderont autant que possible la compatibilité avec la base de programmes existante.
Il ne me paraît pas vraiment judicieux de perdre de la performance actuellement en utilisant 'range()' à la place des appels à de gros 'xrange()' juste pour s'habituer à un langage hypothétique avec des spécifications aucunement figées.
A mon humble avis, on aura le temps de voir python 3000 arriver et ce n'est pas ce style de détails qui doit monopoliser notre attention.
A noter que la future suppression des lambda, map, filter et autres reduce génère actuellement beaucoup de traffic sur comp.lang.python et ça risque d'être le cas pendant encore longtemps. Rien que ces changements-ci demanderont sans doute plus d'effort que la perte d'xrange.
Do Re Mi chel La Si Do
Bonsoir
Python 3000 n'est qu'une hypothèse de travail. Il a toujours été dit qu'il ne sortirait jamais.
Par contre il sert, directement, via les forums, les newsgroups, et les PEP, à définir les évolutions du langage. On remarque, par exemple, que la plupart des nouveautés de Python 2.4 étaient indiquées dans ces démarches.
En ce sens, il est intéressant de tenir compte de ces informations.
Pour les discussions clp, cela peut se résoudre brutalement. Souvenez-vous de la syntaxe des decorators : cela a généré un énorme trafic de messages, qui s'est arrêté net, dès la décision de GVR.
@-salutations
Michel Claveau
Bonsoir
Python 3000 n'est qu'une hypothèse de travail. Il a toujours été dit qu'il
ne sortirait jamais.
Par contre il sert, directement, via les forums, les newsgroups, et les PEP,
à définir les évolutions du langage. On remarque, par exemple, que la
plupart des nouveautés de Python 2.4 étaient indiquées dans ces démarches.
En ce sens, il est intéressant de tenir compte de ces informations.
Pour les discussions clp, cela peut se résoudre brutalement. Souvenez-vous
de la syntaxe des decorators : cela a généré un énorme trafic de messages,
qui s'est arrêté net, dès la décision de GVR.
Python 3000 n'est qu'une hypothèse de travail. Il a toujours été dit qu'il ne sortirait jamais.
Par contre il sert, directement, via les forums, les newsgroups, et les PEP, à définir les évolutions du langage. On remarque, par exemple, que la plupart des nouveautés de Python 2.4 étaient indiquées dans ces démarches.
En ce sens, il est intéressant de tenir compte de ces informations.
Pour les discussions clp, cela peut se résoudre brutalement. Souvenez-vous de la syntaxe des decorators : cela a généré un énorme trafic de messages, qui s'est arrêté net, dès la décision de GVR.
@-salutations
Michel Claveau
Christophe Cavalaria
Do Re Mi chel La Si Do wrote:
Bonsoir
Python 3000 n'est qu'une hypothèse de travail. Il a toujours été dit qu'il ne sortirait jamais.
Ce n'est pas tout a fait exact. Python 3000 n'existera jamais avec ce nom ( sauf si ... ) mais la PEP correspondante est un point ou les devs marquent toutes les choses qu'ils veulent changer mais qui casse la compatibilité. Quand Python 3 sortira ( ce qui arrivera surement un jour, même si l'on ne sait pas quand ) une bonne partie des idées de celui-ci viendront de cette PEP.
Do Re Mi chel La Si Do wrote:
Bonsoir
Python 3000 n'est qu'une hypothèse de travail. Il a toujours été dit qu'il
ne sortirait jamais.
Ce n'est pas tout a fait exact. Python 3000 n'existera jamais avec ce nom
( sauf si ... ) mais la PEP correspondante est un point ou les devs
marquent toutes les choses qu'ils veulent changer mais qui casse la
compatibilité. Quand Python 3 sortira ( ce qui arrivera surement un jour,
même si l'on ne sait pas quand ) une bonne partie des idées de celui-ci
viendront de cette PEP.
Python 3000 n'est qu'une hypothèse de travail. Il a toujours été dit qu'il ne sortirait jamais.
Ce n'est pas tout a fait exact. Python 3000 n'existera jamais avec ce nom ( sauf si ... ) mais la PEP correspondante est un point ou les devs marquent toutes les choses qu'ils veulent changer mais qui casse la compatibilité. Quand Python 3 sortira ( ce qui arrivera surement un jour, même si l'on ne sait pas quand ) une bonne partie des idées de celui-ci viendront de cette PEP.
tiissa
Do Re Mi chel La Si Do wrote:
Python 3000 n'est qu'une hypothèse de travail. Il a toujours été dit qu'il ne sortirait jamais.
C'est une affirmation très hardie ; les informations au sujet de python 3000 étant à ma connaissance imprécises et soumises à interprétation.
[snip]
En ce sens, il est intéressant de tenir compte de ces informations.
Certes, mais dans le cas du range, l'objectif est que tout le monde utilise l'actuel 'xrange' en le faisant remplacer sa contrepartie 'range', moins efficace. Donc décider dès maintenant d'utiliser 'range' de peur que dans longtemps, après avertissements, périodes de compatibilité, etc., un programme ne soit plus utilisable sans ajustement mineur, c'est agir à contresens.
'range' n'est *pas* conseillé à la place de 'xrange'. Le sens de cette portion du PEP est justement le contraire.
Pour les discussions clp, cela peut se résoudre brutalement. Souvenez-vous de la syntaxe des decorators : cela a généré un énorme trafic de messages, qui s'est arrêté net, dès la décision de GVR.
La décision de GvR à ce sujet est déjà connue et les discussions continuent et se relancent régulièrement.
Mais là n'est pas la question, je rappelais simplement que des informations dont il est intéressant de tenir compte, ce n'est pas le renommage de '(x)range' qui va entraîner le plus de conséquences sur le code.
Do Re Mi chel La Si Do wrote:
Python 3000 n'est qu'une hypothèse de travail. Il a toujours été dit qu'il
ne sortirait jamais.
C'est une affirmation très hardie ; les informations au sujet de python
3000 étant à ma connaissance imprécises et soumises à interprétation.
[snip]
En ce sens, il est intéressant de tenir compte de ces informations.
Certes, mais dans le cas du range, l'objectif est que tout le monde
utilise l'actuel 'xrange' en le faisant remplacer sa contrepartie
'range', moins efficace.
Donc décider dès maintenant d'utiliser 'range' de peur que dans
longtemps, après avertissements, périodes de compatibilité, etc., un
programme ne soit plus utilisable sans ajustement mineur, c'est agir à
contresens.
'range' n'est *pas* conseillé à la place de 'xrange'. Le sens de cette
portion du PEP est justement le contraire.
Pour les discussions clp, cela peut se résoudre brutalement. Souvenez-vous
de la syntaxe des decorators : cela a généré un énorme trafic de messages,
qui s'est arrêté net, dès la décision de GVR.
La décision de GvR à ce sujet est déjà connue et les discussions
continuent et se relancent régulièrement.
Mais là n'est pas la question, je rappelais simplement que des
informations dont il est intéressant de tenir compte, ce n'est pas le
renommage de '(x)range' qui va entraîner le plus de conséquences sur le
code.
Python 3000 n'est qu'une hypothèse de travail. Il a toujours été dit qu'il ne sortirait jamais.
C'est une affirmation très hardie ; les informations au sujet de python 3000 étant à ma connaissance imprécises et soumises à interprétation.
[snip]
En ce sens, il est intéressant de tenir compte de ces informations.
Certes, mais dans le cas du range, l'objectif est que tout le monde utilise l'actuel 'xrange' en le faisant remplacer sa contrepartie 'range', moins efficace. Donc décider dès maintenant d'utiliser 'range' de peur que dans longtemps, après avertissements, périodes de compatibilité, etc., un programme ne soit plus utilisable sans ajustement mineur, c'est agir à contresens.
'range' n'est *pas* conseillé à la place de 'xrange'. Le sens de cette portion du PEP est justement le contraire.
Pour les discussions clp, cela peut se résoudre brutalement. Souvenez-vous de la syntaxe des decorators : cela a généré un énorme trafic de messages, qui s'est arrêté net, dès la décision de GVR.
La décision de GvR à ce sujet est déjà connue et les discussions continuent et se relancent régulièrement.
Mais là n'est pas la question, je rappelais simplement que des informations dont il est intéressant de tenir compte, ce n'est pas le renommage de '(x)range' qui va entraîner le plus de conséquences sur le code.
Do Re Mi chel La Si Do
Bonsoir !
'range' n'est *pas* conseillé à la place de 'xrange'. Le sens de cette portion du PEP est justement le contraire.
Pas d'accord. Actuellement, range est un objet de type list ; xrange est un objet de type xrange ; le PEP propose de faire évoluer range vers un type itérable, comme generator. C'est assez différent. Et le PEP parle bien d'abandonner la particularité xrange.
'xrange' en le faisant remplacer sa contrepartie 'range', moins efficace.
La moindre efficacité de range, relativement à xrange est peu importante. En utilisation courante, et réelle, on gagne vraiment peu.
Mais là n'est pas la question, je rappelais simplement que des informations dont il est intéressant de tenir compte, ce n'est pas le renommage de '(x)range' qui va entraîner le plus de conséquences sur le code.
Je rappelle mes propos : "J'ai noté un point qui m'avait échappé". Ce n'est pas le sujet principal du message. Inutile de se focaliser là-dessus. Quand aux changement dans le code, ce n'est pas si simple. J'ai des scripts qui tournent en Australie, aux Philippines, etc. Régions où je ne suis jamais allé. Et la communication avec les utilisateurs finaux n'est pas simple (je ne les connais pas directement). Toute modification, même mineure, peut prendre des mois. Cherchant à limiter les dysfonctionnements futurs, je me dois d'anticiper sur les évolutions syntaxiques, indépendamment de la signification de ces évolutions. Et je ne parle pas des scripts muets qui tournent sur des serveurs difficiles d'accès...
@-salutations
Michel Claveau
Bonsoir !
'range' n'est *pas* conseillé à la place de 'xrange'. Le sens de cette
portion du PEP est justement le contraire.
Pas d'accord. Actuellement, range est un objet de type list ; xrange est un
objet de type xrange ; le PEP propose de faire évoluer range vers un type
itérable, comme generator. C'est assez différent. Et le PEP parle bien
d'abandonner la particularité xrange.
'xrange' en le faisant remplacer sa contrepartie 'range', moins
efficace.
La moindre efficacité de range, relativement à xrange est peu importante. En
utilisation courante, et réelle, on gagne vraiment peu.
Mais là n'est pas la question, je rappelais simplement que des
informations dont il est intéressant de tenir compte, ce n'est pas le
renommage de '(x)range' qui va entraîner le plus de conséquences sur le
code.
Je rappelle mes propos : "J'ai noté un point qui m'avait échappé". Ce n'est
pas le sujet principal du message. Inutile de se focaliser là-dessus.
Quand aux changement dans le code, ce n'est pas si simple. J'ai des scripts
qui tournent en Australie, aux Philippines, etc. Régions où je ne suis
jamais allé. Et la communication avec les utilisateurs finaux n'est pas
simple (je ne les connais pas directement). Toute modification, même
mineure, peut prendre des mois. Cherchant à limiter les dysfonctionnements
futurs, je me dois d'anticiper sur les évolutions syntaxiques,
indépendamment de la signification de ces évolutions. Et je ne parle pas des
scripts muets qui tournent sur des serveurs difficiles d'accès...
'range' n'est *pas* conseillé à la place de 'xrange'. Le sens de cette portion du PEP est justement le contraire.
Pas d'accord. Actuellement, range est un objet de type list ; xrange est un objet de type xrange ; le PEP propose de faire évoluer range vers un type itérable, comme generator. C'est assez différent. Et le PEP parle bien d'abandonner la particularité xrange.
'xrange' en le faisant remplacer sa contrepartie 'range', moins efficace.
La moindre efficacité de range, relativement à xrange est peu importante. En utilisation courante, et réelle, on gagne vraiment peu.
Mais là n'est pas la question, je rappelais simplement que des informations dont il est intéressant de tenir compte, ce n'est pas le renommage de '(x)range' qui va entraîner le plus de conséquences sur le code.
Je rappelle mes propos : "J'ai noté un point qui m'avait échappé". Ce n'est pas le sujet principal du message. Inutile de se focaliser là-dessus. Quand aux changement dans le code, ce n'est pas si simple. J'ai des scripts qui tournent en Australie, aux Philippines, etc. Régions où je ne suis jamais allé. Et la communication avec les utilisateurs finaux n'est pas simple (je ne les connais pas directement). Toute modification, même mineure, peut prendre des mois. Cherchant à limiter les dysfonctionnements futurs, je me dois d'anticiper sur les évolutions syntaxiques, indépendamment de la signification de ces évolutions. Et je ne parle pas des scripts muets qui tournent sur des serveurs difficiles d'accès...
@-salutations
Michel Claveau
Do Re Mi chel La Si Do
Bonsoir !
En fait, la signification de "Python 3000" a évolué dans le temps.
Au début, le terme représentait une ré-écriture complète du langage "from scratch", sans compatibilité arrière garantie (il y avait même eu des discussions sur le (non)-respect de la casse).
Ensuite, c'est devenu une hypothèse de travail, pour étudier des voies d'évolution du langage Python.
En fait, la signification de "Python 3000" a évolué dans le temps.
Au début, le terme représentait une ré-écriture complète du langage "from
scratch", sans compatibilité arrière garantie (il y avait même eu des
discussions sur le (non)-respect de la casse).
Ensuite, c'est devenu une hypothèse de travail, pour étudier des voies
d'évolution du langage Python.
En fait, la signification de "Python 3000" a évolué dans le temps.
Au début, le terme représentait une ré-écriture complète du langage "from scratch", sans compatibilité arrière garantie (il y avait même eu des discussions sur le (non)-respect de la casse).
Ensuite, c'est devenu une hypothèse de travail, pour étudier des voies d'évolution du langage Python.
