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?