[Python-Dev] PEP 382: Namespace Packages

[M.-A. Lemburg]

On 2009-04-15 21:22, P.J. Eby wrote:
> At 02:52 PM 4/15/2009 -0400, A.M. Kuchling wrote:
>> On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
>> > Please see the large number of Zope and PEAK distributions on PyPI as
>> > minimal examples that disprove this being the common use case.  I
>> expect
>> > you will find a fair number of others, as well.
>>    ...
>> > In other words, the "base package" scenario is the exception these
>> days,
>> > not the rule.  I actually know specifically of only one other such
>> > package besides your mx.* case, the logilab ll.* package.
>>
>> Isn't that pretty even, then?  zope.* and PEAK are two examples of one
>> approach; and mx.* and ll.* are two examples that use the base package
>> approach.  Neither approach seems to be the more common one, and both
>> are pretty rare.
> 
> If you view the package listings on PyPI, you'll see that the "pure"
> namespaces currently in use include:
> 
> alchemist.*
> amplecode.*
> atomisator.*
> bda.*
> benri.*
> beyondskins.*
> bliptv.*
> bopen.*
> borg.*
> bud.*
> ...
> 
> This is just going down to the 'b's, looking only at packages whose PyPI
> project name reflects a nested package name, and only including those
> with entries that:
> 
> 1. use setuptools,
> 2. declare one or more namespace packages, and
> 3. do not depend on some sort of "base" or "core" package.
> 
> Technically, setuptools doesn't support base packages anyway, but if the
> organization appeared to be based on a "core+plugins/addons" model (as
> opposed to "collection of packages grouped in a namespace") I didn't
> include it in the list above -- i.e., I'm bending over backwards to be
> fair in the count.

Hmm, setuptools doesn't support the notion of base packages, ie.
packages that provide their own __init__.py module, so I fail
to see how your list or any other list of setuptools-depend
packages can be taken as indicator for anything related to
base packages.

Since setuptools probably introduced the idea of namespace
sharing packages to many authors in the first place, such
a list is even less appropriate to use as sample base.

That said, I don't think such statistics provide any useful
information to decide on the namespace import strategy standard
for Python which is the subject of the PEP.

They just show that one helper-based mechanism is used more than
others and that's simply a consequence of there not being a
standard built-in way of using namespace packages in Python.

Whether base packages are useful or not is really a side aspect
of the PEP and my proposal. I'm more after a method that doesn't
add more .pkg file cruft to Python's import mechanism.

Those .pth files were originally meant to help older Python "packages"
(think the early PIL or Numeric extensions) to integrate nicely into
the new scheme without having to fully support dotted package names
right from the start.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 15 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/