Each Answer to this Q is separated by one/two green lines.
I’m taking a look at how the model system in django works and I noticed something that I don’t understand.
I know that you create an empty
__init__.py file to specify that the current directory is a package. And that you can set some variable in
__init__.py so that import * works properly.
But django adds a bunch of from … import … statements and defines a bunch of classes in
__init__.py. Why? Doesn’t this just make things look messy? Is there a reason that requires this code in
All imports in
__init__.py are made available when you import the package (directory) that contains it.
import dir # can now use dir.something
EDIT: forgot to mention, the code in
__init__.py runs the first time you import any module from that directory. So it’s normally a good place to put any package-level initialisation code.
EDIT2: dgrant pointed out to a possible confusion in my example. In
import something can import any module, not necessary from the package. For example, we can replace it with
import datetime, then in our top level
test.py both of these snippets will work:
import dir print dir.datetime.datetime.now()
import dir.some_module_in_dir print dir.datetime.datetime.now()
The bottom line is: all names assigned in
__init__.py, be it imported modules, functions or classes, are automatically available in the package namespace whenever you import the package or a module in the package.
It’s just personal preference really, and has to do with the layout of your python modules.
Let’s say you have a module called
erikutils. There are two ways that it can be a module, either you have a file called erikutils.py on your
sys.path or you have a directory called erikutils on your
sys.path with an empty
__init__.py file inside it. Then let’s say you have a bunch of modules called
parseutils and you want those to be sub-modules under
erikutils. So you make some .py files called fileutils.py, procutils.py, and parseutils.py:
erikutils __init__.py fileutils.py procutils.py parseutils.py
Maybe you have a few functions that just don’t belong in the
parseutils modules. And let’s say you don’t feel like creating a new module called
miscutils. AND, you’d like to be able to call the function like so:
rather than doing
So because the
erikutils module is a directory, not a file, we have to define it’s functions inside the
In django, the best example I can think of is
django.db.models.fields. ALL the django *Field classes are defined in the
__init__.py file in the django/db/models/fields directory. I guess they did this because they didn’t want to cram everything into a hypothetical django/db/models/fields.py model, so they split it out into a few submodules (related.py, files.py, for example) and they stuck the made *Field definitions in the fields module itself (hence,
__init__.py file allows you to make the internal package structure invisible from the outside. If the internal structure changes (e.g. because you split one fat module into two) you only have to adjust the
__init__.py file, but not the code that depends on the package. You can also make parts of your package invisible, e.g. if they are not ready for general usage.
Note that you can use the
del command, so a typical
__init__.py may look like this:
from somemodule import some_function1, some_function2, SomeObject del somemodule
Now if you decide to split
somemodule the new
__init__.py might be:
from somemodule1 import some_function1, some_function2 from somemodule2 import SomeObject del somemodule1 del somemodule2
From the outside the package still looks exactly as before.