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

[Phillip J. Eby]

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.