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

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 modpython 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