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

[Guido van Rossum]

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

Oh, cool gray area. I propose that if there's no __init__.py it prints
'<path>/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/)