faciliter les imports - danger(s) de cette méthode

Bonjour

J'écris régulièrement des packages qui sont utilisés par d'autres personnes, avec plusieurs modules et, parfois, une (petite) arborescence.

Pour éviter que les utilisateurs aient à connaître très précisément où les classes et les fonctions sont définies et à faire des imports "compliqués", j'ai pris l'habitude d'importer, dans le fichier __init__.py du package ces classes et fonctions qu'ils auront à utiliser.

Par exemple :

Code:

---

1 2 3 4 5

+ package |__ __init__.py |__ module_1.py |__ module_2.py

---

avec module_1.py :

Code:

---

1 2	class Classe_1(object): pass

---

module_2.py :

Code:

---

1 2	class Classe_2(object): pass

---

__init__.py :

Code:

---

1 2 3

from module_1 import Classe_1 from module_2 import Classe_2 __all__ = ['module_1','module_2']

---

Cela permet alors d'écrire dans les scripts utilisant le package :

Code:

---

1 2 3 4

from package import Classe_1, Classe_2 # plutot que # from package.module_1 import Classe_1 # from package.module_2 import Classe_2

---

Ca fonctionne mais je ne suis pas sur de bien mesurer les effets de bord possibles ou les inconvénients de cette méthode.
Avez-vous un avis là dessus ?

Citation:

---

Envoyé par plxpy

Ca fonctionne mais je ne suis pas sur de bien mesurer les effets de bord possibles ou les inconvénients de cette méthode.
Avez-vous un avis là dessus ?

---

C'est une convention que j'utilise aussi.
Vous définissez des sortes d'"alias" qui masquent l'implémentation physique. C'est une bonne chose.
Tant que vos noms sont associés à des boîtes (classes), les "utilisateurs" pourront passer par le chemin physique ou par l'alias, sans soucis.
Si vous avez besoin d'avoir des variables globales... danger.

- W
PS:

Citation:

---

from module_1 import Classe_1
from module_2 import Classe_2
__all__ = ['module_1','module_2']

---

Je n'ai pas testé votre construction.
__all__ limitant les entrées du dictionnaire importé via "from XXX import *", si __init__.py ne sert qu'à déclarer ce que vous voulez montrer, je n'en vois pas trop l'utilité.
Ceci dit les noms que vous voulez rendre accessible sont Classe_1 et _2 et non les module_X

Merci pour cette réponse wiztricks.

C'est vrai que, si le seul but est uniquement d' "exporter" les classes Classe_1 et Classe_2, aller initialiser __all__ comme je l'ai fait n'est pas nécessaire.

Disons que je le fais pour "ne pas fermer la porte" et rendre possible des imports plus classiques (là, pour le coup, il faut connaître finement où sont définies les classes et les fonctions - surtout si ça bouge ...).

Ca me permet notamment, en phase de développement, d'importer des choses que je veux tester et qui, au final, sont inutiles pour les utilisateurs et qu'ils n'ont pas à importer. La documentation que j'écris indique bien de faire les imports sous la forme "from package import Classe_1" et si les utilisateurs importent autre chose, autrement, je ne réponds plus de rien !

Citation:

---

... Disons que je le fais pour "ne pas fermer la porte" et rendre possible des imports plus classiques ...

---

Initialiser __all__ comme je le fais(ais) n'apporte rien si ce n'est du bruit. On peut tout à fait faire des imports "complets" (explicites) sans cela. Donc c'est une habitude que je vais essayer de perdre, ça rendra __init__.py plus lisible.

Bonjour,

Citation:

---

Envoyé par plxpy

Initialiser __all__ comme je le fais(ais) n'apporte rien si ce n'est du bruit. On peut tout à fait faire des imports "complets" (explicites) sans cela. Donc c'est une habitude que je vais essayer de perdre, ça rendra __init__.py plus lisible.

---

Et la pollution du Namespace ?
Sans __all__

Code:

---

1 2 3

>>> from Foo import * >>> print locals() {'__builtins__': <module '__builtin__' (built-in)>, 'module_1': <module 'Foo.module_1' from 'Foo/module_1.pyc'>, '__package__': None, 'Classe_1': <class 'Foo.module_1.Classe_1'>, 'Classe_2': <class 'Foo.module_2.Classe_2'>, '__name__': '__main__', 'module_2': <module 'Foo.module_2' from 'Foo/module_2.pyc'>, '__doc__': None}

---

Avec

Code:

---

1 2 3

>>> from Foo import * >>> print locals() {'__builtins__': <module '__builtin__' (built-in)>, '__package__': None, 'Classe_1': <class 'Foo.module_1.Classe_1'>, 'Classe_2': <class 'Foo.module_2.Classe_2'>, '__name__': '__main__', '__doc__': None}

---

La construction de votre __init__.py ayant pour but, comme le dit wiztricks, de masquent l'implémentation physique (comprendre Pour éviter que les utilisateurs aient à connaître très précisément...) une ligne supplémentaire pour palier au non suivit de votre doc n'est pas si inutile que cela non ?
Je ne vois pas en quoi cette construction pourrait s'avérer dangereuse dans le cadre de variables globales.

@+

@PauseKawa

Concernant le Namespace, quand j'importe tout du package, je n'ai pas la même chose que toi (du coup j'ai essayé en 2.6 et en 2.7 mais ça ne change rien).

Sans initialisation de __all__

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

plx@sony:~/Bureau$ python2.6 Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from pprint import pprint >>> from package import * >>> pprint(locals()) {'Classe_1': <class 'package.module_1.Classe_1'>, 'Classe_2': <class 'package.module_2.Classe_2'>, '__builtins__': <module '__builtin__' (built-in)>, '__doc__': None, '__name__': '__main__', '__package__': None, 'module_1': <module 'package.module_1' from 'package/module_1.py'>, 'module_2': <module 'package.module_2' from 'package/module_2.py'>, 'pprint': <function pprint at 0xb777c56c>} >>>

---

avec initialisation __all__ = ['module_1','module_2']

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

plx@sony:~/Bureau$ python2.6 Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from pprint import pprint >>> from package import * >>> pprint(locals()) {'__builtins__': <module '__builtin__' (built-in)>, '__doc__': None, '__name__': '__main__', '__package__': None, 'module_1': <module 'package.module_1' from 'package/module_1.pyc'>, 'module_2': <module 'package.module_2' from 'package/module_2.pyc'>, 'pprint': <function pprint at 0xb76ea56c>} >>>

---

c'est-à-dire que sans initialisation de __all__, on a 2 noms visibles supplémentaires, Classe_1 et Classe_2.

Du coup, j'ai l'impression qu'on n'est pas phasé pour discuter des avantages/inconvénients de la chose.
Travaillerais-tu en version 3 ? Est-ce que cela pourrait expliquer les différences dans locals() ?

Salut,

Ce qui peut être em... avec cette technique est d'avoir à mettre à jour le fichier __init__.py et la cohérence entre les symboles recopiés suivant un import * ou pas.

conventions?

• déclarer un __all_ dans les modules importés,
• effectuer un from module import * dans __init__ (çà suit la déclaration précédente)
• définir le __all__ du __init__ en fonction de ce qui aura été récupéré dans le dico.

- W

Citation:

---

Envoyé par PauseKawa

Je ne vois pas en quoi cette construction pourrait s'avérer dangereuse dans le cadre de variables globales.

---

c'est le from XXX import * qui ne fait pas toujours ce qu'on veut lorsque les variables globales sont des "valeurs" partagées plutôt que des adresses (boîtes).
L'import XX est plus consistant dans ce cas puisque ce sera la variable du module XX peut importe sa forme.

Bonjour wiztricks

euh ... j'ai décroché !

Bonjour,

Tout ce que je voulais dire c'est qu'a vouloir de l'user-friendly autant aller jusqu'au bout du concept d'usabilité. C'est plus lourd et tout un chacun préfèreras limiter cela avec une doc (i.e et si les utilisateurs importent autre chose, autrement, je ne réponds plus de rien !. Voir la doc de PIL par exemple.).
Pour ce qui est de la visibilité des variables dites ici 'globales' dans le cadre d'un from x import * cela rentre dans la première idée. C'est sans doute l'un des (meilleur ?) arguments pour la seconde option ;p.
Pour ce qui est des conventions il me semble que certains modules communs (trou de mémoire...) utilisent des imports dynamiques dans l'__init__, je vais rechercher cela.

@plxpy Je ne vois aucune différence dans nos résultats.

@+

@PauseKawa

Citation:

---

@plxpy Je ne vois aucune différence dans nos résultats.@+

---

Dans ce que tu as posté, avec __all__, les noms 'module_1' et 'module_2' ne font pas partie de l'espace local. Problème de copier/coller ?

(d'ailleurs, la taille de l'ascenseur horizontal est très différente de celle pour "sans" !)

Citation:

---

Envoyé par plxpy

Dans ce que tu as posté, avec __all__, les noms 'module_1' et 'module_2' ne font pas partie de l'espace local. Problème de copier/coller ?

---

Exact, c'est les classe_* que j'ai mis dans __all__.
Pour reprendre au propre :
Sans __all__ et avec module_2 tel que

Code:

---

1 2 3 4

import module_3   class Classe_2(object): pass

---

Code:

---

1 2 3

>>> from package import * >>> locals() {'__builtins__': <module '__builtin__' (built-in)>, 'module_1': <module 'package.module_1' from 'package/module_1.pyc'>, 'module_3': <module 'package.module_3' from 'package/module_3.pyc'>, '__package__': None, 'Classe_1': <class 'package.module_1.Classe_1'>, 'Classe_2': <class 'package.module_2.Classe_2'>, '__name__': '__main__', 'module_2': <module 'package.module_2' from 'package/module_2.pyc'>, '__doc__': None}

---

Avec __init__ tel que

Code:

---

1 2 3

from module_1 import Classe_1 from module_2 import Classe_2 __all__ = ['module_1', 'module_2']

---

Code:

---

1 2 3

>>> from package import * >>> locals() {'__builtins__': <module '__builtin__' (built-in)>, 'module_1': <module 'package.module_1' from 'package/module_1.pyc'>, 'module_2': <module 'package.module_2' from 'package/module_2.pyc'>, '__name__': '__main__', '__package__': None, '__doc__': None}

---

(Je pense qu'on est bon la) C'est dans cette optique que je parle de pollution et que je trouve que l'utilisation de __all__ n'est pas si mal.

La remarque de wiztricks pour ce qui est des "valeurs" partagées dans ce genre de conception est judicieuse. Cela demande un bon suivit des valeurs/variables.

@+