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

Phillip J. Eby pje at telecommunity.com
Mon Jan 7 00:41:00 CET 2008

At 02:10 PM 1/6/2008 -0800, Brett Cannon wrote:

My question becomes whether we want to allow something like this even if we explicitly state people should not use this mechanism to override pre-existing modules. Do we want people tossing stuff into the 'databases' package, or should the packages in the stdlib be considered sacred?

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)

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.

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.

More information about the Python-Dev mailing list