[Python-Dev] Dropping init.py requirement for subpackages (original) (raw)

Talin talin at acm.org
Thu Apr 27 10:44:18 CEST 2006

Guido van Rossum <guido python.org> writes:

The requirement that a directlry must contain an init.py file before it is considered a valid package has always been controversial. It's designed to prevent the existence of a directory with a common name like "time" or "string" from preventing fundamental imports to work. But the feature often trips newbie Python programmers (of which there are a lot at Google, at our current growth rate we're probably training more new Python programmers than any other organization worldwide .

Might I suggest an alternative?

I too find it cumbersome to have to litter my directory tree with init.py iles. However, rather than making modules be implicit ("Explicit is better than implicit"), I would rather see a more powerful syntax for declaring modules.

Specifically, what I would like to see is a way for a top-level init.py to explicitly list which subdirectories are modules. Rather than spreading that information over a bunch of different init.py files, I would much rather have the information be centralized in a single text file for the whole package.

Just as we have an all variable that indicates which symbols are to be exported, we could have a 'submodules' array which explicitly calls out the list of submodule directory names. Or perhaps more simply, just have some code in the top-level init.py that creates (but does not load) the module objects for the various sub-modules.

The presence of "init.py" could perhaps also indicate the root of a standalone module tree; submodules that don't have their own init.py, but which are declared indirectly via an ancestor are assumed by convention to be 'component' modules which are not intended to operate outside of their parent. (In other words, the presence of the init.py signals that that tree is separately exportable.)

I'm sure that someone who is familiar with the import machinery could whip up something like this in a matter of minutes.

As far as the "compatibility with tools" argument goes, I say, break em :) Those tool programmers need a hobby anyway :)

-- Talin

More information about the Python-Dev mailing list