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

Christian Heimes lists at cheimes.de
Mon Jan 7 01:10:25 CET 2008


Phillip J. Eby wrote:
> This is actually an excellent point, given that the actual intended 
> use of namespace packages is to allow an *organization* to control a 
> namespace: e.g. zope.* and zc.* packages, osaf.* packages, 
> etc.  Using names that have meaning (like "email" or "databases") 
> sort of goes against the whole point of namespace packages in the first place.
> 
> For some reason, I wasn't thinking about that when the original post 
> came through.
> 
> So, now that I've thought about it, I'm -1 on the stdlib using 
> *top-level* namespace packages to sort out its contents (e.g. 
> "databases" as a top-level package name)

I don't have a strong opinion as PJE but tend to agree with his point of
view. We must not reserve a complete set of top level names and close
them for 3rd party software.

*Either* we create subject area packages (e.g. databases, web) and open
them for 3rd party software *or* we create a top level name space for
Python's stdlib and reserve it for our own purpose.

For the initial example of "databases.sqlite" I think py.db.sqlite has a
nice ring to it.

> If we want to allow separately-distributed *upgrades* or bugfix 
> releases of projects (such as an updated sqlite module), then using 
> 2nd-level namespace packages like "std.databases.*" would allow that.

I like to see a possibility to easily upgrade, bugfix or extend a stdlib
package with 3rd party extensions. PEP 297
(http://www.python.org/dev/peps/pep-0297/) contains some useful ideas.

> Note, by the way, that this implies that somebody creating their own 
> Oracle driver would *not* be expected to put it into 
> std.databases.  Again, the whole point of a namespace package is to 
> reserve that namespace for packages produced by a particular 
> organization, similar to the way e.g. the 'org.apache.projectname' 
> packages in Java work.

The initial idea behind the new packages for Python 3.0 weren't really
based on name space packages. It was more about grouping related modules
by subject.

Christian



More information about the Python-Dev mailing list