Discussion :

[plxpy]

Bonjour

Je suis en train de modifier tout un tas de scripts et de packages pour qu'ils puissent être utilisés aussi bien avec la version 2(.7) qu'avec la version 3(.6) de python. Dans un deuxième temps, je basculerai entièrement en version 3.

Pour ce faire, j'utilise le package future et notamment le script futurize qui modifie mes scripts version 2 et me mache le travail.

Parmi ces modifications, il y en a certaines dont je ne saisis pas bien l'intérêt.

Les range sont laissés en l'état dans les boucles for (même si un range v3 équivaut à un xrange v2), ok, mais un import est ajouté : from builtins import range qui n'a d'effet que pour l'interpréteur en version 2.

Je ne vois pas l'intérêt de cet import (comme celui, analogue, pour zip par exemple) et fonctionnellement, on peut faire sans.

Qu'est-ce qui m'échappe ?

[lg_53]

En Python 2, la fonction range retourne une liste. En python 3, la fonction range renvoie un générateur et il faut faire list(range(10)) en Python 3 pour avoir l'équivalence avec le range(10) de Python 2.

Je ne sais pas ce qu'il y a dans ce package builtins, mais je présume que ça pallie la différence que je viens de mentionner.

PS : Fonctionnellement, tu "peux" faire sans car en pratique on utilise le range comme ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for i in range(10):

et que range soit un générateur ou une liste ca fonctionne donc pareil.
Mais si j'avais un code comme ceci, qui fonctionne par distinction de cas selon le type d'une variable :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
a=range(10)
if isinstance(a,list):
...
else :
...

là ca ne va pas se passer pareil !

[plxpy]

En Python 2, la fonction range retourne une liste. En python 3, la fonction range renvoie un générateur et il faut faire list(range(10)) en Python 3 pour avoir l'équivalence avec le range(10) de Python 2.

oui, je sais tout ça. Je l'ai indiqué dans mon post (range vs xrange dans une boucle for).

Ce que je cherche à éviter (si possible), c'est d'introduire des imports inutiles pendant cette phase transitoire et d'avoir à me reposer la question quand je basculerai définitivement en v3.

Si dans la version 2, on (c'est mon code et celui de collègues) a jugé raisonnable d'utiliser range et non xrange (la liste générée restait petite), ça peut rester comme ça, sans avoir à reproduire le comportement de python3 (là, avec l'import, on passe par une classe newrange de future quand on est en v2).

En v3, un "from builtins import range" sert à utiliser le range original pour peu qu'il ait été écrasé par une (re-)définition.

Je veux juste shunter ces imports dans la mesure où je ne loupe pas quelque chose

[wiztricks]

Salut,

Ce que je cherche à éviter (si possible), c'est d'introduire des imports inutiles pendant cette phase transitoire et d'avoir à me reposer la question quand je basculerai définitivement en v3.

Le but de cette bibliothèque est de créer un code qui soit compatible Python2 et Python3.
Si vous partez de Python2, un z = range(10) sera remplacé par un z = list(range(10)) sans import du "range" v3.
Si vous partez d'un code Python3, çà ne changera rien dans les instructions, mais çà ajoutera l'import du range v3.
Dans tous les cas, çà s'efforce de respecter l'intention du programmeur i.e. produire le même résultat sauf que le chemin pour aller de 2 à 3 sera différent de celui à prendre pour aller de 3 à 2.

-*- edit -*-
Est-ce que "futurize" ajoute cet import? Dans votre cas, il ne devrait pas (contrairement à pasteurize).
Oops, en plus j'ai testé avant de poster il ajoute l'import.
Mais il ajoute aussi from __future__ import print_function s'il trouve un "print" en ré-écrivant l'instruction, si c'est Python 2. Dans un cas comme dans l'autre, l'instruction originale n'est remplacée que si nécessaire.
C'est là qu'il faut relire attentivement la description de ce que çà fait:

futurize passes Python 2 code through all the appropriate fixers to turn it into valid Python 3 code, and then adds __future__ and future package imports.

For conversions from Python 3 code to Py2/3, use the pasteurize script instead. This converts Py3-only constructs (e.g. new metaclass syntax) and adds __future__ and future imports to the top of each module.

In both cases, the result should be relatively clean Py3-style code that runs mostly unchanged on both Python 2 and Python 3.

Et çà dit que çà fabrique un code Python3 qui pourra tourner sous Python2 et Python3 sans trop de changements grâce à l'ajout d'import astucieux.
Donc de fait, il y aura from __future__ import print_function et from builtins import range superflus pour ceux qui font le chemin dans un seul sens. 2to3 devrait suffire dans votre cas (éviter les nettoyages) - c'est ce que j'ai utilisé il y a longtemps.

- W