Discussion :

[Sve@r]

Bonjour à tous
Aujourd'hui je franchis le pas et je commence à porter mes projets sous Python3

Et de suite je suis confronté à un souci d'import.

En effet, pour ne pas me mélanger entre le "après" et le "avant", mes codes que je migre sous python3 ont alors une extension en ".py3". Or, il semblerait qu'on ne puisse pas importer un script ayant cette extension.

En effet, si par exemple j'écris un fichier "toto.py" je peux alors demander ensuite un import toto mais si le fichier se nomme "toto.py3" ben là que dalle, python me dit que le module "toto" n'existe pas.

Pourtant le suffixe "py3" existe puisque le programme "2to3" inclus une option permettant de le positionner. J'ai même d'ailleurs fait un test en créant dans un dossier X un script "toto.py" et un "essai.py" qui importe toto (en Python2) puis demandé un "2to3 --output=Y --add-suffix=3 X" => ça a créé un dossier "Y" contenant "toto.py3" et "essai.py3" mais là ben ça ne fonctionne quand-même pas => "essai" ne peut pas importer "toto".

Donc en fait à partir de là j'ai juste deux questions
1) peut-on importer un fichier ".py3" (ou mieux demander que le "py3" soit l'extension par défaut dans les import) ?
2) est-ce bien conventionnel/usité/standard/propre de mettre ".py3" comme extension de ses scripts P3 ?

Merci à tous de votre soutien

[lg_53]

Salut Sve@r

J'utilise Python3 depuis plusieurs années maintenant et j'avoue ne jamais avoir vu l'extension .py3. Même dans des packages disponibles à la fois en python2 et 3 (avec version différente).

La différence python2/python3 doit être faite à l'échelle du projet pour moi, et non à l'échelle du fichier. Donc tu as ton dossier avec tout ton projet dedans. Et juste à côté un autre dossier pour la v3, ayant exactement la même hierarchie et contenant des fichiers portant le même nom.

Je n'ai jamais eu à utiliser 2to3, mais il me semble qu'il fournit aussi une possibilité pour convertir un projet complet. Dans ce cas là je suis curieux de voir si 2to3 te mets les fichiers à côté des originaux en y mettant l'extension .py3 pour les différencier, ou bien s'il te créé un nouveau dossier et y met les fichiers converti à l'intérieur.

EDIT : Je viens de relire ton post et visiblement 2to3 créer un nouveau dossier avec dedans des .py3. Bon, ceci dit l'ajout du suffixe .py3 est une option, sans doute là pour les utilisateurs qui ne traite simplement qu'avec des scripts tout en un fichier.

[Sve@r]

La différence python2/python3 doit être faite à l'échelle du projet pour moi, et non à l'échelle du fichier. Donc tu as ton dossier avec tout ton projet dedans. Et juste à côté un autre dossier pour la v3, ayant exactement la même hierarchie et contenant des fichiers portant le même nom.

Oui c'est ce que j'ai fait heureusement (sinon c'était la cata). J'ai créé une nouvelle branche, y ai déversé le contenu de la branche précédente puis ensuite je traite les fichiers un à un pour au final n'avoir que du v3.
Mais c'était aussi pour une question de lisibilité (exemple je tape ls je vois de suite si je suis dans une branche P2 ou P3). Certes à plus ou moins long terme le P2 disparaitra complètement de mon home mais pour l'instant...

Je n'ai jamais eu à utiliser 2to3, mais il me semble qu'il fournit aussi une possibilité pour convertir un projet complet. Dans ce cas là je suis curieux de voir si 2to3 te mets les fichiers à côté des originaux en y mettant l'extension .py3 pour les différencier, ou bien s'il te créé un nouveau dossier et y met les fichiers converti à l'intérieur.

Par défaut il ne fait rien d'autre que raconter ce qu'il faut changer. Si on rajoute l'option "-W" il réécrit alors le fichier d'origine (qui est donc perdu). Si on demande l'option "--add-suffix=3" là il le copie en "py3". Et si on demande en plus l'option arborescente (avec "--output=dest") et qu'on lui donne un dossier à manger il traite tout son contenu et chaque fichier traité est copié dans "dest" en "py3".

[lg_53]

Mais c'était aussi pour une question de lisibilité (exemple je tape ls je vois de suite si je suis dans une branche P2 ou P3). Certes à plus ou moins long terme le P2 disparaitra complètement de mon home mais pour l'instant...

Ca ne répond pas vraiment à la question initialement posée, mais tu peux trouver des parades pour contourner le problème tant que les versions cohabitent.

Pour le ls, tu peux par exemple créer un fichier vide à la racine de ton projet (ou bien dans tous les dossiers), portant un nom du genre __versionxx__.txt
Tu peux également reconfigurer ta console pour qu'elle t'affiche dans l'invit le chemin complet de là où tu te trouve (comme ca quelle que soit la commande que tu souhaite faire, le chemin t'indique quel version c'est via le nom de la branche.

Pour conaitre dans le terminal python la version que tu manipules, tu peux aussi ajouter une variable global à chacun de tes fichiers du genre :
__python_version__ = 3
voire ajouter cette variable directement dans les __init__.py si tu as packagé ton projet.

[Sve@r]

Ouaip. Effectivement en vous lisant je pense que "py3" serait en fait une "fausse" bonne idée. Apparemment c'est possible mais si je dois me lancer dans une usine à gaz pour ça... C'est toutefois bizarre que "2to3" le propose en option. Preuve que d'autres ont dû tout de même y penser.

En tout cas, porter du P2 vers P3 me fait en plus prendre conscience de trucs que j'ai fait mais que j'aurais pas dû. Par exemple jusqu'à présent, quand je voulais vérifier si le type d'un truc était de type "machin", j'utilisais le module "types" sous forme isinstance(truc, types.MachinType) ce qui, sous P3, devient bêtement isinstance(truc, machin) car le module "types" s'est radicalement allégé.
Or j'ai découvert que ce type d'instruction était aussi possible sous P2 (depuis la v2.2) et en lisant la doc, qu'elle était même recommandée à la place de la première (accessoirement je me demande aussi maintenant à quoi sert ce module).

J'ai donc filtré tous mes sources P2 (un gros paquets) pour remplacer la première syntaxe par la seconde. Heureusement "vi" est pas mal pour ce genre de travail parce que sinon j'avais pas fini.

Enfin merci à vous de vos précieux avis et conseils qui m'ont bien aidé dans mes choix.

[dad3zero]

Pour répondre à la seconde question, non, ce n'est pas une bonne pratique, un module Python est un fichier texte avec l'extension .py

Migrer vers Python 3 devrait se faire dans l'autre sens, c'est à dire rendre le code compatible Python3 (futur et autres) et basculer vers Python 3. Pour moi, le script 2to3 est un truc legacy.

Par exemple jusqu'à présent, quand je voulais vérifier si le type d'un truc était de type "machin", j'utilisais le module "types" sous forme isinstance(truc, types.MachinType) ce qui, sous P3, devient bêtement isinstance(truc, machin) car le module "types" s'est radicalement allégé.
Or j'ai découvert que ce type d'instruction était aussi possible sous P2 (depuis la v2.2) et en lisant la doc, qu'elle était même recommandée à la place de la première (accessoirement je me demande aussi maintenant à quoi sert ce module).

Lorsque je lis ça, il me semble toujours nécessaire de rajouter que en Python, c'est vérifier le type qui est une mauvaise pratique… Bien entendu c'est présumer de l'usage, mais rappelez-vous que le principe du DuckTyping fait que dans la plupart des cas, on ne test pas le type.

[wiztricks]

Salut,

1) peut-on importer un fichier ".py3" (ou mieux demander que le "py3" soit l'extension par défaut dans les import) ?

Oui grâce à importlib. Cependant, c'est pas des plus faciles à utiliser. Fut un temps, je m'étais amusé à attraper les "import" pour mettre à jour "à la volée" des fichiers .uic pour Qt. Ça fonctionne très bien sauf que importlib était tellement instable dans les versions 3.3, 3.4,... que c'est un peu prise de tête à maintenir.
Normalement, çà devrait être stable depuis 3.6 mais il faut trouver des exemples de code et les adapter ou plonger dans la lecture studieuse des sources.

2) est-ce bien conventionnel/usité/standard/propre de mettre ".py3" comme extension de ses scripts P3 ?

La convention est toujours ".py".
Et bien qu'on puisse résoudre le problème côté Python (voir ce qui précède), d'autres outils importants comme les IDE risquent de ne pas le supporter (et là pour mettre à jour....).

La moins mauvaise solution (mais peut être riche) est d'utiliser un gestionnaire de configuration comme Git.

- W