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

Brett Cannon brett at python.org
Sun Jan 6 23:10:46 CET 2008


On Jan 6, 2008 2:01 PM, Steven Bethard <steven.bethard at gmail.com> wrote:
> On Jan 6, 2008 1:07 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> > At 12:03 PM 1/6/2008 -0700, Steven Bethard wrote:
> > >Maybe the situation is different here, but having someone installing a
> > >different version of sqlite behind my back makes me nervous.
> >
> > Er, someone who?  Behind whose back?  I'm quite confused by what it
> > is that's making you nervous.
> >
> > Do you worry about people bundling newer versions of say, the
> > optparse module or wsgiref with their applications?  If so, why?  Or
> > if not, what's different?
>
> I worry about exactly the pyxml problem. Someone installs pyxml on my
> system, pyxml replaces xml.parsers.expat with a different version of
> pyexpat than the rest of Python, and then programs like mod_python
> crash because the two components were compiled against different
> versions of a common library. Here's the link again that I posted
> earlier:
>
>     http://www.dscpl.com.au/wiki/ModPython/Articles/ExpatCausingApacheCrash
>
> Note that this all happens "behind my back" because I didn't know that
> pyxml would be replacing pyexpat in such a way that would cause this
> crash.  In fact, I didn't even know that pyxml was installing pyexpat.

This is my worry as well (and why I was going to phrase the situation
in a more "should this be considered" tone than the way Christian
stated it.  =) .

But then again none of this is impossible even if we do leave out
extending the namespace.  Tweaking a package's __path__ value after
the fact is not exactly hard.  So even if we don't do this we are not
preventing anyone from extending the namespace, just discouraging.

My question becomes whether we want to allow something like this even
if we explicitly state people should not use this mechanism to
override pre-existing modules.  Do we want people tossing stuff into
the 'databases' package, or should the packages in the stdlib be
considered sacred? I am leaning towards not, but that's because I
personally like knowing that if I import something from a stdlib
namespace it is from the stdlib.  I don't want some bug report from a
naive user of cx_Oracle ending up in the stdlib because the import
came from the 'databases' package. And I would guess that if you don't
consider this a stdlib thing but for any third-party package that
other third-party packages would not love other packages mucking with
their namespace.

-Brett


More information about the Python-Dev mailing list