My package has the following structure:
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
...
I'm not sure how the __init__.py
files should be correctly written.
The __init__.py #1
looks like:
__all__ = ['mapper', 'vehicle']
import mapper
import vehicle
But how should for example __init__.py #2
look like? Mine is:
__all__ = ['basemapper', 'lxml']
from basemaper import *
import lxml
When should be __all__
used?
Your __init__.py
should have a docstring.
Although all the functionality is implemented in modules and subpackages, your package docstring is the place to document where to start. For example, consider the python email
package. The package documentation is an introduction describing the purpose, background, and how the various components within the package work together. If you automatically generate documentation from docstrings using sphinx or another package, the package docstring is exactly the right place to describe such an introduction.
For any other content, see the excellent answers by firecrow and Alex Martelli.
My own __init__.py
files are empty more often than not. In particular, I never have a from blah import *
as part of __init__.py
-- if "importing the package" means getting all sort of classes, functions etc defined directly as part of the package, then I would lexically copy the contents of blah.py
into the package's __init__.py
instead and remove blah.py
(the multiplication of source files does no good here).
If you do insist on supporting the import *
idioms (eek), then using __all__
(with as miniscule a list of names as you can bring yourself to have in it) may help for damage control. In general, namespaces and explicit imports are good things, and I strong suggest reconsidering any approach based on systematically bypassing either or both concepts!-)
Source: Stackoverflow.com