It used to be a required part of a package (old, pre-3.3 "regular package", not newer 3.3+ "namespace package").
Here's the documentation.
Python defines two types of packages, regular packages and namespace packages. Regular packages are traditional packages as they existed in Python 3.2 and earlier. A regular package is typically implemented as a directory containing an
__init__.pyfile. When a regular package is imported, this__init__.pyfile is implicitly executed, and the objects it defines are bound to names in the package’s namespace. The__init__.pyfile can contain the same Python code that any other module can contain, and Python will add some additional attributes to the module when it is imported.
But just click the link, it contains an example, more information, and an explanation of namespace packages, the kind of packages without __init__.py.
It used to be a required part of a package (old, pre-3.3 "regular package", not newer 3.3+ "namespace package").
Here's the documentation.
Python defines two types of packages, regular packages and namespace packages. Regular packages are traditional packages as they existed in Python 3.2 and earlier. A regular package is typically implemented as a directory containing an
__init__.pyfile. When a regular package is imported, this__init__.pyfile is implicitly executed, and the objects it defines are bound to names in the package’s namespace. The__init__.pyfile can contain the same Python code that any other module can contain, and Python will add some additional attributes to the module when it is imported.
But just click the link, it contains an example, more information, and an explanation of namespace packages, the kind of packages without __init__.py.
Files named __init__.py are used to mark directories on disk as Python package directories.
If you have the files
mydir/spam/__init__.py
mydir/spam/module.py
and mydir is on your path, you can import the code in module.py as
import spam.module
or
from spam import module
If you remove the __init__.py file, Python will no longer look for submodules inside that directory, so attempts to import the module will fail.
The __init__.py file is usually empty, but can be used to export selected portions of the package under more convenient name, hold convenience functions, etc.
Given the example above, the contents of the init module can be accessed as
import spam
This answer is based on this webpage.
Still confused about what __init__ should be used for
How exactly does __init__.py influence module search order?
What is __init__.py for?
What do you have in your __init__.py files?
Videos
I get the idea that it somehow initiates the module but I sometimes see that it only has imports in it, some others it contains a bunch of methods, sometimes if you don't have that file then other modules cannot import correctly other scripts... I'm so confused
Today at work I had an argument with a senior developer from my team. The reason was him putting a class body into a package __init__.py file. I pointed out it shouldn't be there and I'd never expect to find it there. He claims there's nothing wrong with putting a short class like this in init file. At this point I should probably mention both of us have similar (low) level of experience with Python, as we transitioned from Java monolithic projects to Python microservices quite recently. We couldn't find an agreement.
My points for not putting class definitions in init and moving them to the separate files was:
-
__init__.pyis a requirement for a directory to be registered as a module. Usually, I don't put any content in it. Sometimes, I write imports clauses of classes and functions that are meant to be used in the code importing this module. This makes them clearly visible among other, implementation-details parts of the code. -
It's good to keep classes in a separate files. I'm not sure about that one, maybe it's a good convention for other languages that I started treating as a good habit in general, but I think it improves the readability and simplifies the structure of the package.
His points were:
-
It's a short class extending an abstract class and it's not meant to be changed by anyone. I don't really know what does it have to do with anything.
-
__init__.pyis executed immediately after the import, it can have initialization code. Registering a class structure is sort of initialization meant for that package. -
IDE will find the declaration for you anyway, no matter where it is.
To me, his behavior is even more unconditioned, because the class definition looks like this:
from .package.a import a
from .package.b import b
class Foo:
def a(self, x):
return a(x)
def b(self, b):
return b(x)As you can see, class methods are imported from the separate files. If you're already using imports at that level, why don't just import the whole class? I don't get it...
Unluckily, I was unable to find any PEPs or other official recommendations on what should actually be stored in `__init__.py` file. Looking through the answers on StackOverflow I get mixed responses. Some people do actually put classes or other definitions there, some leave it empty or just do basic imports. To me, it's a subjective matter and it's up to you on how do you decide to use this file. However, when I consider reasons for and against mentioned above, I'm coming to the conclusion it's better not to do anything besides top-level imports in __init__.py. What is your opinion? Can you share any popular code bases utilizing init files in any other way than doing just simple imports?
EDIT: formatting