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

[Guido van Rossum]

(Context: There's a large crowd with pitchforks and other sharp pointy
farm implements just outside the door of my office at Google. They are
making an unbelievable racket. It appears they are Google engineers
who have been bitten by a misfeature of Python, and they won't let me
go home before I have posted this message.)

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 :-).

One particular egregious problem is that *subpackage* are subject to
the same rule. It so happens that there is essentially only one
top-level package in the Google code base, and it already has an
__init__.py file. But developers create new subpackages at a
frightening rate, and forgetting to do "touch __init__.py" has caused
many hours of lost work, not to mention injuries due to heads banging
against walls.

So I have a very simple proposal: keep the __init__.py requirement for
top-level pacakages, but drop it for subpackages. This should be a
small change. I'm hesitant to propose *anything* new for Python 2.5,
so I'm proposing it for 2.6; if Neal and Anthony think this would be
okay to add to 2.5, they can do so.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)