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

[Barry Warsaw]

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 "<path>/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