[Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages (original) (raw)

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