[Python-Dev] PEP 382: Namespace Packages

[M.-A. Lemburg]

On 2009-04-07 19:46, P.J. Eby wrote:
> 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.)

The purpose of the PEP is to create a standard for namespace packages.
That's orthogonal to trying to enhance or change some existing
techniques.

I don't see the emphasis in the PEP on Linux distribution support and the
remote possibility of them wanting to combine separate packages back
into one package as good argument for adding yet another separate hierarchy
of special files which Python scans during imports.

That said, note that most distributions actually take the other route:
they try to split up larger packages into smaller ones, so the argument
becomes even weaker.

It is much more important to standardize the approach than to try
to extend some existing trickery and make them even more opaque than
they already are by introducing yet another level of complexity.

My alternative approach builds on existing methods and fits nicely
with the __init__.py approach Python has already been using for more
than a decade now. It's transparent, easy to understand and provides
enough functionality to build upon - much like the original __init__.py
idea.

I've already laid out the arguments for and against it in my
previous reply, so won't repeat them here.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 14 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2009-03-19: Released mxODBC.Connect 1.0.1      http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/