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

[Phillip J. Eby]

At 03:01 PM 1/6/2008 -0700, Steven Bethard wrote:
>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.

Ah -- so this is 100% orthogonal to namespace packages, since this is 
something that can happen even without __path__ munging.

Namespace packages don't actually make this any easier, either, so I 
don't see how this reflects on the proposal.  Without a namespace 
package, packages earlier on sys.path *completely* override those 
that are installed later.  With a namespace package, only the 
specific submodules/subpackages that exist can override the ones that 
appear later.

IOW, without namespace packages, if you have two 'foo' packages, one 
containing 'bar' and the other both 'bar' and 'baz', then with 
namespace packages you'll always see a foo.bar and a foo.baz, with 
the contents of foo.bar depending on path order.  *Without* namespace 
packages, the exact same thing is true of foo.bar, but foo.baz will 
also be either visible or invisible depending on the path order.

In other words, the status quo actually has *more* variability of what happens.

So, while it might be a good idea to advise people against replacing 
packages they don't "own" or at least making it prominently visible 
that a package replaces something in the stdlib, it doesn't (so far 
as I can tell) have anything to do with the merits of namespace 
packages one way or the ohter.

Unless there is something else I'm missing?