"Paul Moore" <[EMAIL PROTECTED]> wrote: > > On 5/31/06, Brett Cannon <[EMAIL PROTECTED]> 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. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
