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/