[Python-3000] packages in the stdlib

[Josiah Carlson]

"Paul Moore" <p.f.moore at gmail.com> wrote:
> 
> On 5/31/06, Brett Cannon <brett at python.org> wrote:
> > Why would a 3rd-party module be installed into the stdlib namespace?
> > net.jabber wouldn't exist unless it was in the stdlib or the module's author
> > decided to be snarky and inject their module into the stdlib namespace.
> 
> Do you really want the stdlib to "steal" all of the simple names (like
> net, gui, data, ...)? While I don't think it's a particularly good
> idea for 3rd party modules to use such names, I'm not too keen on
> having them made effectively "reserved", either.

This is one reason why I was suggesting the 'py' (or other) top level
package; then we would really have py.net, py.gui, py.data, etc., which
would presumably avoid name collisions, and wouldn't reserve the generic
names.

As for 3rd party modules, that is those modules that would (or should)
go into the site-packages right now, I'm not sure I like the idea of
having them inject themselves into the "package heirarchy" of the
standard library, though it wouldn't be too terribly difficult with an
import hook combined with a setup hook*.

 - Josiah

* The setup hook creates and/or modifies a special "3rd party packages"
bit of metadata (presumably in XML).  This metadata describes two
things; where the module lies in the heirarchy registry, and where it
actually lies in the filesystem.  The import hook would adjust the
__all__ or module/package dictionary on import to include the names of
the modules that are importable, as known by the metadata registry.