[Python-Dev] Dropping __init__.py requirement for subpackages

[Talin]

Guido van Rossum <guido <at> 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