[Python-Dev] PEP 382: Namespace Packages

[P.J. Eby]

At 04:58 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
>On 2009-04-07 16:05, P.J. Eby wrote:
> > At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
> >> >> Wouldn't it be better to stick with a simpler approach and look for
> >> >> "__pkg__.py" files to detect namespace packages using that O(1)
> >> check ?
> >> >
> >> > Again - this wouldn't be O(1). More importantly, it breaks system
> >> > packages, which now again have to deal with the conflicting file names
> >> > if they want to install all portions into a single location.
> >>
> >> True, but since that means changing the package infrastructure, I think
> >> it's fair to ask distributors who want to use that approach to also take
> >> care of looking into the __pkg__.py files and merging them if
> >> necessary.
> >>
> >> Most of the time the __pkg__.py files will be empty, so that's not
> >> really much to ask for.
> >
> > This means your proposal actually doesn't add any benefit over the
> > status quo, where you can have an __init__.py that does nothing but
> > declare the package a namespace.  We already have that now, and it
> > doesn't need a new filename.  Why would we expect OS vendors to start
> > supporting it, just because we name it __pkg__.py instead of __init__.py?
>
>I lost you there.
>
>Since when do we support namespace packages in core Python without
>the need to add some form of magic support code to __init__.py ?
>
>My suggestion basically builds on the same idea as Martin's PEP,
>but uses a single __pkg__.py file as opposed to some non-Python
>file yaddayadda.pkg.

Right... which completely obliterates the primary benefit of the 
original proposal compared to the status quo.  That is, that the PEP 
382 way is more compatible with system packaging tools.

Without that benefit, there's zero gain in your proposal over having 
__init__.py files just call pkgutil.extend_path() (in the stdlib 
since 2.3, btw) or pkg_resources.declare_namespace() (similar 
functionality, but with zipfile support and some other niceties).

IOW, your proposal doesn't actually improve the status quo in any way 
that I am able to determine, except that it calls for loading all the 
__pkg__.py modules, rather than just the first one.  (And the 
setuptools implementation of namespace packages actually *does* load 
multiple __init__.py's, so that's still no change over the status quo 
for setuptools-using packages.)