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

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

On 4/26/06, Barry Warsaw <barry at python.org> wrote:

On Wed, 2006-04-26 at 10:16 -0700, Guido van Rossum wrote:

> 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. But if it's there, then nothing changes, right? IOW, if we want to expose names in the subpackage's namespace, we can still do it in the subpackage's init.py. It's just that otherwise empty subpackage init.py files won't be required.

Correct. This is an important clarification.

What would the following print?

import toplevel.sub1.sub2 print toplevel.sub1.sub2.file If it's "/sub1/sub2" then that kind of breaks a common idiom of using os.path.dirname() on a module's file to find co-located resources. Or at least, you have to know whether to dirname its file or not (which might not be too bad, since you'd probably know how that package dir is organized anyway).

Oh, cool gray area. I propose that if there's no init.py it prints '/sub1/sun2/' i.e. with a trailing slash; that causes dirname to just strip the '/'. (It would be a backslash on Windows of course).

I dunno. Occasionally it trips me up too, but it's such an obvious and easy fix that it's never bothered me enough to care.

But you're not a newbie. for a newbie who's just learned about packages, is familiar with Java, and missed one line in the docs, it's an easy mistake to make and a tough one to debug.

I can't think of an example, but I suppose it's still possible that lifting this requirement could cause some in-package located data directories to be mistakenly importable. I'd be somewhat more worried about frameworks that dynamically import things having to be more cautious about cleansing their import() arguments now.

But (assuming 2.6 and absolute import) what would be the danger of importing such a package? Presumably it contains no *.py or *.so files so there's no code there; but even so you'd have to go out of your way to import it (since if the directory exists it can't also be a subpackage or submodule name that's in actual use).

I'd be -1 but the remote possibility of you being burned at the stake by your fellow Googlers makes me -0 :).

I'm not sure I understand what your worry is.

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

More information about the Python-Dev mailing list