what is __init__.py used for?

[zelzel.zsu]

I am a new learner of Python Programming Language.
Now. I am reading a book.
In the section relating to module, I see an example.
the directory tree looks like below:
root\
system1\
__init__.py
utilities.py
main.py
other.py
system2\
__init__.py
utilities.py
main.py
other.py
system3\ # Here or elsewhere
__init__.py # Your new code here
myfile.py

question
==========
I was wonderring ... what is the __init__.py used for ?
This question may seems to be stupid for an expert.
But, if you can give the answer, it will be helpful for me.

thanks.

 

[Lutz Horn]

* (e-mail address removed):

root\
system1\
__init__.py
utilities.py
main.py
other.py ....
I was wonderring ... what is the __init__.py used for ?
This question may seems to be stupid for an expert.

The __init__.py is needed for Python to recognize the system1 directory
as an importable module.

Lutz

 

[Simon Brunning]

I am a new learner of Python Programming Language.
Welcome!

I was wonderring ... what is the __init__.py used for ?
This question may seems to be stupid for an expert.
But, if you can give the answer, it will be helpful for me.

The __init__.py files make Python treat the directories as packages -
see http://docs.python.org/tut/node8.html#SECTION008400000000000000000.

We have to do something about those URLs!

 

[=?ISO-8859-1?Q?Walter_D=F6rwald?=]

I am a new learner of Python Programming Language.
Now. I am reading a book.
In the section relating to module, I see an example.
the directory tree looks like below:
root\
system1\
__init__.py
utilities.py
main.py
other.py
system2\
__init__.py
utilities.py
main.py
other.py
system3\ # Here or elsewhere
__init__.py # Your new code here
myfile.py

question
==========
I was wonderring ... what is the __init__.py used for ?
This question may seems to be stupid for an expert.
But, if you can give the answer, it will be helpful for me.

If the root directory is on the Python search path, you can do "import
system2.other" or "from system2 import other", to import the other.py
module. But you can also do "import system2". This means that the source
code for the system2 module has to live somewhere. __init.py inside the
directory with the same name is this "somewhere". Without this
__init__.py inside the system2 directoy you couldn't import other.py
because Python doesn't know where the source code for system2 lives and
refuses to treat system2 as a package.

Hope that helps,
Walter Dörwald

 

[John Roth]

I am a new learner of Python Programming Language.
Now. I am reading a book.
....

==========
I was wonderring ... what is the __init__.py used for ?
This question may seems to be stupid for an expert.
But, if you can give the answer, it will be helpful for me.

__init__.py is used for two things. One is as a flag to
indicate that the python programs in the directory are
part of a module.

The other is as the module itself. Let's take a simple
example. Assume you have a directory named breakfast
which contains modules named spam.py, eggs.py,
toast.py and jam.py, and that the directory containing
breakfast is on the PYTHONPATH.

If it try to import spam.py by writing

import breakfast.spam

it won't work because the breakfast directory
doesn't contain an __init__.py file.

If I then add __init__.py to the breakfast directory,
the import will work, and the result will be *two*
modules loaded. The first module will be bound to
the identifier 'breakfast' in your module. It will be
completely empty except for the identifier 'spam'
which will have the spam module bound to it.

This means that if the spam module contains,
for example, an identifier named "vikings", then I
can refer to it as breakfast.spam.vikings.

The real kicker here is that when I say that the
first module will be completely empty, it's not
quite true. First, it will have some standard
identifiers that all modules have, and second
it will have anything you put into the __init__.py
module file. This last is an advanced feature, and
you're well advised to stay away from it until
you've got a lot more experiance.

HTH

John Roth

 

[George Sakkis]

The other is as the module itself. Let's take a simple
example. Assume you have a directory named breakfast
which contains modules named spam.py, eggs.py,
toast.py and jam.py, and that the directory containing
breakfast is on the PYTHONPATH.

If it try to import spam.py by writing

import breakfast.spam

it won't work because the breakfast directory
doesn't contain an __init__.py file.

If I then add __init__.py to the breakfast directory,
the import will work, and the result will be *two*
modules loaded. The first module will be bound to
the identifier 'breakfast' in your module. It will be
completely empty except for the identifier 'spam'
which will have the spam module bound to it.

There is also an alternative form of import that does not load the
intermediate modules (actually packages), only the last one:
Here you can refer to names defined in breakfast.spam as spam.eat(),
spam.slice, etc. However you can't refer to breakfast; if you do,
you'll get a NameError exception:
NameError: name 'breakfast' is not defined

In either form of import though, the __init__.py has to be in the
breakfast directory.

HTH,
George

 

[Terry Hancock]

The real kicker here is that when I say that the
first module will be completely empty, it's not
quite true. First, it will have some standard
identifiers that all modules have, and second
it will have anything you put into the __init__.py
module file.

It's not at all uncommon, for example, for __init__.py
to contain a set of imports:

from SubMod1 import *
import SubMod2 as sub

etc,

this is one way to create the "interface" that the package
will present to you when you import it.

This last is an advanced feature, and
you're well advised to stay away from it until
you've got a lot more experiance.

Not until you are writing Python packages, anyway.
But it's probably a good idea to know what it does
so that you can read what it's doing in packages you
use and/or study (and studying existing packages
is one of the best ways to learn once you've gotten
beyond the basic hurdle of writing simple programs).