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

Guido van Rossum guido at python.org
Wed Apr 26 19:16:59 CEST 2006

(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/)

More information about the Python-Dev mailing list