Mon colis a la structure suivante:
mobilescouter/
__init__.py #1
mapper/
__init__.py #2
lxml/
__init__.py #3
vehiclemapper.py
vehiclefeaturemapper.py
vehiclefeaturesetmapper.py
...
basemapper.py
vehicle/
__init__.py #4
vehicle.py
vehiclefeature.py
vehiclefeaturemapper.py
...
Je ne sais pas comment les __init__.py
fichiers doivent être correctement écrits.
Le __init__.py #1
ressemble à:
__all__ = ['mapper', 'vehicle']
import mapper
import vehicle
Mais à quoi devrait par exemple __init__.py #2
ressembler? Le mien est:
__all__ = ['basemapper', 'lxml']
from basemaper import *
import lxml
Quand faut-il l' __all__
utiliser?
Réponses:
__all__
est très bon - il aide à guider les instructions d'importation sans importer automatiquement les modules http://docs.python.org/tutorial/modules.html#importing-from-a-packageen utilisant
__all__
etimport *
est redondant, seul__all__
est nécessaireJe pense que l'une des raisons les plus puissantes à utiliser
import *
dans un__init__.py
pour importer des packages est de pouvoir refactoriser un script qui s'est développé en plusieurs scripts sans casser une application existante. Mais si vous concevez un package depuis le début. Je pense qu'il est préférable de laisser les__init__.py
fichiers vides.par exemple:
puis l'application grandit et maintenant c'est un dossier entier
alors le script init peut dire
afin qu'un script écrit pour faire ce qui suit ne se casse pas pendant le changement:
la source
__all__
etimport *
est redondant",__all__
est utilisé par le consommateur du module, etfrom foo import *
est utilisé par le module lui-même pour en utiliser d'autres ....using __all__ and import * is redundant, only __all__ is needed
En quoi sont-ils redondants? Ils font des choses différentes.Mes propres
__init__.py
fichiers sont vides le plus souvent. En particulier, je n'ai jamais faitfrom blah import *
partie de__init__.py
- si "importer le package" signifie obtenir toutes sortes de classes, fonctions, etc. définies directement dans le cadre du package, alors je copierais lexicalement le contenu deblah.py
dans le package à la__init__.py
place et supprimeraisblah.py
( la multiplication des fichiers sources ne sert à rien ici).Si vous insistez pour soutenir les
import *
idiomes (eek), alors utiliser__all__
(avec une liste de noms aussi minuscule que vous pouvez vous en faire) peut aider à contrôler les dégâts. En général, les espaces de noms et les importations explicites sont de bonnes choses, et je suggère fortement de reconsidérer toute approche basée sur le contournement systématique de l'un ou des deux concepts! -)la source
import *
vous devez accepter inconditionnellement tout le framework dans son ensemble, même les fonctionnalités que vous n'utiliserez jamais. rester__init__.py
vide vous donne plus de chances que la sémantique tout ou rien. pensez tordu.from mobilescouter import A, B
est juste une ligne de code et vous n'avez pas de projet avec 666 classes et chacune avec son propre fichier, non? si vous en avez deux ou plusimport *
dans votre code, vous remplissez l'espace de noms avec des déchets potentiels et vous oublierez rapidement d'oùA
vient. Et si un emballage supérieur faisait de même? vous récupérez tous les sous-packages et sous-sous-packages. comme le dit le zen de python, l'explicite vaut mieux que l'implicite.Votre
__init__.py
devrait avoir un docstring .Bien que toutes les fonctionnalités soient implémentées dans des modules et des sous-packages, votre package docstring est l'endroit pour documenter où commencer. Par exemple, considérons le package python
email
. La documentation du package est une introduction décrivant l'objectif, le contexte et la manière dont les différents composants du package fonctionnent ensemble. Si vous générez automatiquement de la documentation à partir de docstrings en utilisant sphinx ou un autre package, le package docstring est exactement le bon endroit pour décrire une telle introduction.Pour tout autre contenu, consultez les excellentes réponses de Firecrow et Alex Martelli .
la source
__init__.py
duemail
colis suit-il cette directive? Je vois une docstring sur une seule ligne qui ne fait pas grand-chose pour expliquer "comment les différents composants du package fonctionnent ensemble".