Discussion :

[rambc]

Bonjour,
voici une arborescence que j'ai :

Code :

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

1
2
3
4
doc_tools
    + checkOptionColor.py
    + defaultColor.py
    + optionsBlock.py

Dans optionsBlock.py, il y a l'import suivant :

Code :

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

from . import checkOptionColor

Dans checkOptionColor.py, il y a l'import suivant :

Code :

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

from . import defaultColor

En l'état cela fonctionne mais je ne peux plus travailler directement avec checkOptionColor.py pour par exemple faire des tests.

Je me doute que je m'y prends mal au niveau de la structure de mon code mais pour le moment je laisse de côté la restructuration des modules, car une fois mon projet fini j'étudierais un peu mieux QUOI utilise QUOI.

Mon problème serait de savoir quoi changer pour pouvoir utiliser checkOptionColor.py tout seul.

Quelles sont les bonnes pratiques à avoir en Python 3 pour les import ? Je précise que les horreurs que j'utilise pour le moment se sont imposées à moi lors du passage à Python 3.

Toute info. est la bienvenue.

[PauseKawa]

Bonjour rambc,

Tu vas sans aucun doute avoir des réponses plus pro mais à mon niveau (autodidacte-épicurien, c'est dire...) j'ai pris pour habitude d'inclure un if __name__ == "__main__" et de calquer l'appelant sur celui ci.

Ceci dit je n'ai sans doute pas compris ta question vis à vis des imports sous Python 3 (il y as des changements la aussi ?) puisque je n'arrive pas a me résoudre à passer le pas

Bon code

[rambc]

Tu vas sans aucun doute avoir des réponses plus pro mais à mon niveau (autodidacte-épicurien, c'est dire...)

Je suis autodidacte moi aussi mais pas trop épicurien. Je programme des choses pour me faciliter la tache.

j'ai pris pour habitude d'inclure un if __name__ == "__main__" et de calquer l'appelant sur celui ci.

On est d'accord, un code "moche" comme celui ci-dessous marche.

Code :

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

1
2
3
4
if __name__ == '__main__':
    import defaultColors
else:
    from . import defaultColors

Avec Python 2, il suffisait de faire :

Code :

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

import defaultColors

... je n'arrive pas a me résoudre à passer le pas

Je ne sais pas si c'est un défaut de Python 3 ou bien si cela reflète une mauvaise pratique. C'est le seul reproche que j'aurais à faire à Python 3, ou à ma façon de structurer mon projet.

[rambc]

Il semblerait que mon problème n'ait pas de solution autre que de mieux structurer mon code d'après ceci.

Faut-il à chaque fois créer un module pour ne pas importer des fichiers Python seuls directement ?

Toute info ou bonne pratique est bienvenue.

[kango]

bonjour,

doc_tools est un package python ?

si oui, que donne un import comme ceci:

Code :

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

import doc_tools.defaultColors

et si doc_tools est lui même un sous-package de appli:

Code :

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

import appli.doc_tools.defaultColors

[rambc]

doc_tools est un package python ?

Non. Certains de mes fichiers ne font pas partie du module doc_tools, ie ne sont pas dans __init__.py. Les complications doivent venir de là.

En fait je n'avais pas besoin d'avoir accès à certaines méthodes, donc certains fichiers Python ne faisaient pas partie des modules bien qu'utilisés à l'intérieur du dossier.

Cela ne doit pas être une bonne pratique. Je pense que je vais tout mettre dans des modules, y compris les fichiers Python secondaires.

[wiztricks]

Salut,

Ce qui se rapporte a ton cas dans les RN de Python3K me semble être:

The only acceptable syntax for relative imports is from .[module] import name. All import forms not starting with . are interpreted as absolute imports. (PEP 0328)

Et comme c'est une question d'ambiguïté, la règle est d'utiliser des "import absolus" sauf dans le cas ou on ne peut pas faire autrement...

Règle 1: les imports sont toujours de la forme myapp.a.b.c

Mais si tu ne l'as pas fait, c'est probablement parce que tu as un problème de "structure".

Si tu considères les modules comme des "boîtes", ils ont:
- un chemin d'accès physique
- des interfaces
- une réalisation
- des dépendances avec d'autres boîtes (sinon il n'y aurait pas d'import)
La structure de nommage par défaut étant l'arborescence des fichiers, c'est une structure hiérarchique 'trop simple'.

A priori "defaultColor.py" existe parce qu'utilisé en tant que tel 'ailleurs'. Au nom, tu as du définir un "type" Color histoire de savoir de quoi on parle dans les différents modules qui ont besoin de...

Visuellement, il y a sans doute des modules à un niveau équivalent à "doc_tools" qui importent "defaultColor" sans avoir besoin du reste.

Je suppose que tu as d'autres types qui sont dans le même cas que Color: une solution pourrait être de les placer dans un module de même niveau que "doc_tools": appelons le "types".

Il contiendrait le type 'Color' qui définit Color.default

dans checkOptionColor.py, on peut maintenant remplacer

Code :

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

1
2
3
4
from . import defaultColors, par
import myapp.types as t
ou
from myapp.types import Color

Ce qui permet de rendre la règle 1 applicable.

Un des gros soucis des espaces de noms Python est qu'ils ressemblent à une hiérarchie similaire à celle d'un système de fichiers mais qu'ils ne permettent pas d'utiliser les alias de façon aussi 'simple'.
=> dès qu'on a des dépendances entre les sous-arbres, impossible de la délier dans passer par la création d'un nœud de même niveau qui permet de réaliser la fonction alias.
- W

[rambc]

Merci pour cette réponse détaillée qui confirme une mauvaise habitude que je vais changer à l'avenir. Dorénavant, même si un fichier me paraît très secondaire, il fera partie du module.

Ma mauvaise habitude a dû être importée de ma petite pratique du php avec les include.

[wiztricks]

Merci pour cette réponse détaillée qui confirme une mauvaise habitude que je vais changer à l'avenir. Dorénavant, même si un fichier me paraît très secondaire, il fera partie du module.

Tous les scripts sont déjà dans le module 'myapp'.
Le soucis est la structuration des arbres qui sont dessous pour éviter les dépendances circulaires et (dans le cas présent) latérales.

Ma mauvaise habitude a dû être importée de ma petite pratique du php avec les include.

Ben dans la plupart des langages, l'espace d'adressage - la mécanique de résolution des noms - reste locale ou est explicitée dans le code.
Avec Python, tu as, en gros, deux niveaux:

• les modules (et les scripts qui sont dedans): qui définissent un espace d'adressage absolu permettant de faire les "imports"
• la construction du "globals" de chaque module via les différents "imports".

Un truc qui n'est pas intuitif est qu'un module Python est un "singleton": il n'est instancié qu'une seule fois et ses variables sont "globales" (tant qu'on utilise import et non from car dans ce cas elles sont 'locales' )
- W

[rambc]

Merci pour ces précisions. Pour m'aider à revoir la structure de mon code, je t'ai posé une petite question ici.