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

Barry Warsaw barry at python.org
Wed Apr 26 19:50:20 CEST 2006

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.

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

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

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

-Barry

-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/python-dev/attachments/20060426/f8ce6e56/attachment.pgp

More information about the Python-Dev mailing list