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

[Guido van Rossum]

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/)