A couple things you could do to improve your organization, if only to adhere to some popular Python conventions and standards.
If you search this topic, you will inevitably run across people recommending the PEP8 guidelines. These are the de facto canonical standards for organizing python code.
Modules should have short, all-lowercase names. Underscores can be
used in the module name if it improves readability. Python packages
should also have short, all-lowercase names, although the use of
underscores is discouraged.
Based on these guidelines, your project modules should be named like this:
foo/
__init__.py
foo.py
module1.py
module2.py
module3.py
I find it’s generally best to avoid importing modules unnecessarily in __init__.py unless you’re doing it for namespace reasons. For example, if you want the namespace for your package to look like this
from foo import Foo
instead of
from foo.foo import Foo
Then it makes sense to put
from .foo import Foo
in your __init__.py. As your package gets larger, some users may not want to use all of the sub-packages and modules, so it doesn’t make sense to force the user to wait for all those modules to load by implicitly importing them in your __init__.py. Also, you have to consider whether you even want module1, module2, and module3 as part of your external API. Are they only used by Foo and not intended to be for end users? If they’re only used internally, then don’t include them in the __init__.py
I’d also recommend using absolute or explicit relative imports for importing sub-modules. For example, in foo.py
Absolute
from foo import module1
from foo import module2
from foo import module3
Explicit Relative
from . import module1
from . import module2
from . import module3
This will prevent any possible naming issues with other packages and modules. It will also make it easier if you decide to support Python3, since the implicit relative import syntax you’re currently using is not supported in Python3.
Also, files inside your package generally shouldn’t contain a
if __name__ == '__main__'
This is because running a file as a script means it won’t be considered part of the package that it belongs to, so it won’t be able to make relative imports.
The best way to provide executable scripts to users is by using the scripts or console_scripts feature of setuptools. The way you organize your scripts can be different depending on which method you use, but I generally organize mine like this:
foo/
__init__.py
foo.py
...
scripts/
foo_script.py
setup.py