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

Guido van Rossum guido at python.org
Mon Jan 7 01:03:44 CET 2008

On Jan 6, 2008 3:35 PM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:

On Jan 6, 2008 3:28 PM, Oleg Broytmann <phd at phd.pp.ru> wrote: > Now I think - if we don't want a separate Python's top-level namespace > may be we should think about a separate top-level non-Python's (3rd > parties') namespace? With it we could have database.sqlite (Python's > sqlite) and user.database.sqlite (a newer version); and by doing import > database.sqlite you know exactly what version you are importing.

Bleh. I'm +1 on allowing third-party additions to the same 'database' namespace that the stdlib puts packages in. People will just have to get used to the package, and not the namespace, determining who to complain to. In theory, it might make sense to allow libraries to "close" some namespaces to deal with Brett's worry, but I think the consenting adults rule says not to bother.

There seems to be a misunderstanding. This is not going to happen for standard library package names. I'm fine with inventing mechanisms to allow 3rd party packages to beo cobbled together from multiple contributions (it would seem to make sense for e.g. Twisted or Zope). But I am absolutely squarely against 3rd party installs adding to (or worse, overriding) standard library package names. This is (to me) simple common sense, the reason being "knowing who to blame". We get enough bug reports in the Python tracker about 3rd party software as it is.

(In general I'm not keen on attempts to create a single unified ontology for library modules. It's like expecting all doctors in town to live on the same street. But my feelings on keeping a clean demarcation between standard and 3rd party are much stronger.)

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

More information about the Python-Dev mailing list