[Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages

[M.-A. Lemburg]

On 2008-01-06 16:33, Christian Heimes wrote:
> Hello!
> 
> We are discussing name space packages on the stdlib reorg list. For
> Python 3.0 we plan to organize the packages by purpose, e.g. put all
> database related packages like sqlite and shelve in a 'databases' name
> space.

Regardless of whether this would really be helpful or not (I used
to be in favor of this some time ago, but then realized that this
doesn't really buy you anything much), please be aware that by
using new generic top-level names you are likely going to get
into conflict with existing applications.

'databases' will likely work since most apps will use 'database'
as module or package name.

> Of course we want to have the name spaces extensible by 3rd party
> software. 

This is not a good idea. The standard lib should not be extensible
by 3rd party packages, instead they should use their own top-level
package and deal with whatever namespace extension mechanism is
used in that package.

> The Python world as currently two ways to create extensible
> name space packages: pkgutil and pkg_resource.

I don't think pkg_resources should go into Python 2.6 as is -
for the reasons I've stated last year when this question
came up.

I also don't like the import mechanism hackery that's being
used in setuptools to get namespace packages working.

IMHO, it would be a lot cleaner to extend the existing import
mechanism to support search continuation, ie. have the import find
mechanism continue the search for a sub-package if it doesn't
find the module in the first instance of a top-level package
directory.

E.g. say you want to import 'a.c' and you have directories
on you sys.path:

libs1/a/
libs1/a/__init__.py
libs1/a/b.py
libs2/a/
libs2/a/__init__.py
libs2/a/c.py

the import mechanism would look in libs1/a/, see that c.py is
not available, then continue the search and find libs2/a/c.py.

This is a sketch, but I think you get the idea.

Next, we add a per-user site-packages directory to the standard
sys.path, and then we could get rid of most of the setuptools
import and sys.path hackery, making it a lot cleaner.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 07 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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