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

[Guido van Rossum]

On Jan 6, 2008 4:10 PM, Christian Heimes <lists at cheimes.de> wrote:
> 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.

Why not? 3rd party software can copy the same hierarchy under its own
toplevel package, e.g. zope.db, zope.net, etc.

Regarding using common words, either the stdlib grabs these, or
*nobody* gets to use them (for fear of conflicting with some other 3rd
party package grabbing the same).

> *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.

Java's example notwithstanding, I don't want "py" or "python" to be
part of the stdlib package namespace. *If* (part of) the stdlib has to
live under a single distinguished name, pick something like "std" or
"core". When I'm using Python I already know I'm using Python, I don't
want to be reminded of that fact on every import line.

> > 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.

I see mostly possibilities for abuse here. Linux vendors can install
bugfixes or using their own packaging system.

> > 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.

Right.

> 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.

See my previous post. This is only mildly useful.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)