I am a newbie just getting started with Python. I have trouble understanding the statement "The __init__.py files are required to make Python treat the directories as containing packages; this is done to prevent directories with a common name, such as string, from unintentionally hiding valid modules that occur later on the module search path"

Let's say i have a directory structure as shown below:
rootDir (let's say this is in sys.path )
-> filex.py

rootDir
-> _init_.py
-> temp
-> _init_.py
-> filex.py

Without having __init__.py, i cannot access rootDir/temp/filex.py unless i have rootDir/temp in the sys.path. With __init__.py defined as shown above, however, i can access it as a package. Having said this i don't understand the statement "this is done to prevent directories with a common name, such as string, from unintentionally hiding valid modules that occur later on the module search path". Can someone please clarify with a use case? Where is the question of hiding the module come into the picture.

Thanks

Recommended Answers

All 4 Replies

I think the point is that directories have many other reasons to exist than being python packages. So if you write a python package named 'books' for example. You can create other 'books' directories here and there, python will still find the package 'books' because it has an __init__.py file.

I think the point is that directories have many other reasons to exist than being python packages. So if you write a python package named 'books' for example. You can create other 'books' directories here and there, python will still find the package 'books' because it has an __init__.py file.

Thanks for your reply. Well, without defining a directory as a package (with __init__.py) there's no way python is going to find any other modules inside a directory unless the directory is in the sys.path. To me, there's no explicit package statement like you have in java, which can be defined in every file that's part of a package. That's why probably you have to define __init__.py across the entire directory structure of a package. Other than that i don't understand the "hiding valid modules" factor completely.

Thanks for your reply. Well, without defining a directory as a package (with __init__.py) there's no way python is going to find any other modules inside a directory unless the directory is in the sys.path. To me, there's no explicit package statement like you have in java, which can be defined in every file that's part of a package. That's why probably you have to define __init__.py across the entire directory structure of a package. Other than that i don't understand the "hiding valid modules" factor completely.

I the "hiding valid modules" mean that if sys.path contains [..., "A", ..., "B",...]
and that directory A and B both have a subdirectory C, and B/C contains foo.py, then the statement "import C.foo" could fail because python would look in A/C instead of looking in B/C. If A/C doesn't have an __init__.py, this can't happen.

I the "hiding valid modules" mean that if sys.path contains [..., "A", ..., "B",...]
and that directory A and B both have a subdirectory C, and B/C contains foo.py, then the statement "import C.foo" could fail because python would look in A/C instead of looking in B/C. If A/C doesn't have an __init__.py, this can't happen.

Well, that's a generic issue with the search path anyways. That's going to happen even if it's not a package. Say you have two directories "/opt/check/A" and "/usr/check/B" and both are in the sys.path [ A, B ]. If you have a module say "fact.py" inside A and B, import fact is going to load the one under A thereby hiding the one under B. But the hiding factor that's mentioned in our current discussion is that an arbitrary directory could hide a package. that's what i couldn't understand because any arbitrary directory cannot hide a package. Only a package can hide another package.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.