The __init__.py file lets the Python interpreter know that a directory contains code for a Python module. An __init__.py file can be blank. Without one, you cannot import modules from another folder into your project. The role of the __init__.py file is similar to the __init__ function in a Python class.
The __init__.py files are required to make Python treat directories containing the file as packages. This prevents directories with a common name, such as string , unintentionally hiding valid modules that occur later on the module search path.
Within __init__.py , we import all the modules that we think are necessary for our project.
@Mike's answer is correct but too imprecise. It is true that Python 3.3+ supports Implicit Namespace Packages that allows it to create a package without an __init__.py
file. This is called a namespace package in contrast to a regular package which does have an __init__.py
file (empty or not empty).
However, creating a namespace package should ONLY be done if there is a need for it. For most use cases and developers out there, this doesn't apply so you should stick with EMPTY __init__.py
files regardless.
To demonstrate the difference between the two types of python packages, lets look at the following example:
google_pubsub/ <- Package 1
google/ <- Namespace package (there is no __init__.py)
cloud/ <- Namespace package (there is no __init__.py)
pubsub/ <- Regular package (with __init__.py)
__init__.py <- Required to make the package a regular package
foo.py
google_storage/ <- Package 2
google/ <- Namespace package (there is no __init__.py)
cloud/ <- Namespace package (there is no __init__.py)
storage/ <- Regular package (with __init__.py)
__init__.py <- Required to make the package a regular package
bar.py
google_pubsub
and google_storage
are separate packages but they share the same namespace google/cloud
. In order to share the same namespace, it is required to make each directory of the common path a namespace package, i.e. google/
and cloud/
. This should be the only use case for creating namespace packages, otherwise, there is no need for it.
It's crucial that there are no __init__py
files in the google
and google/cloud
directories so that both directories can be interpreted as namespace packages. In Python 3.3+ any directory on the sys.path
with a name that matches the package name being looked for will be recognized as contributing modules and subpackages to that package. As a result, when you import both from google_pubsub
and google_storage
, the Python interpreter will be able to find them.
This is different from regular packages which are self-contained meaning all parts live in the same directory hierarchy. When importing a package and the Python interpreter encounters a subdirectory on the sys.path
with an __init__.py
file, then it will create a single directory package containing only modules from that directory, rather than finding all appropriately named subdirectories outside that directory. This is perfectly fine for packages that don't want to share a namespace. I highly recommend taking a look at Traps for the Unwary in Python’s Import System to get a better understanding of how Python importing behaves with regular and namespace package and what __init__.py
traps to watch out for.
__init__.py
files if you want to create namespace packages. Only create namespace packages if you have different libraries that reside in different locations and you want them each to contribute a subpackage to the parent package, i.e. the namespace package.__init__py
to your directories because 99% of the time you just want to create regular packages. Also, Python tools out there such as mypy
and pytest
require empty __init__.py
files to interpret the code structure accordingly. This can lead to weird errors if not done with care.My answer only touches the surface of how regular packages and namespace packages work, so take a look at the following resources for further information:
Python 3.3+ has Implicit Namespace Packages that allow it to create a packages without an __init__.py
file.
Allowing implicit namespace packages means that the requirement to provide an
__init__.py
file can be dropped completely, and affected ... .
The old way with __init__.py
files still works as in Python 2.
If you have setup.py
in your project and you use find_packages()
within it, it is necessary to have an __init__.py
file in every directory for packages to be automatically found.
Packages are only recognized if they include an
__init__.py
file
UPD: If you want to use implicit namespace packages without __init__.py
you just have to use find_namespace_packages()
instead
Docs
I would say that one should omit the __init__.py
only if one wants to have the implicit namespace package. If you don't know what it means, you probably don't want it and therefore you should continue to use the __init__.py
even in Python 3.
Based on my experience, even with python 3.3+, an empty __init__.py
is still needed sometimes. One situation is when you want to refer a subfolder as a package. For example, when I ran python -m test.foo
, it didn't work until I created an empty __init__.py
under the test folder. And I'm talking about 3.6.6 version here which is pretty recent.
Apart from that, even for reasons of compatibility with existing source code or project guidelines, its nice to have an empty __init__.py
in your package folder.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With