[Python-Dev] Namespace collision between lib/xml and site-packages/xml

[Guido van Rossum]

> On July 26 I reported that the new xml package in the standard library
> collides with and overrides the xml package from the xml-sig that may be
> installed in site-packages. This is still the case. The new package does
> not have the same functionality as the one in site-packages, and hence
> my application (and others relying on similar functionality) gets an
> import error. I understood that it was planned that the new library xml
> package would check for the site-package version, and transparently hand
> over to it if it existed. It's not really an option to remove/rename the
> xml package in the std lib, or to break existing xml-based code...
> 
> Of course, this might be fixed by 2.0b1, or is it a feature that will be
> frozen out <wry smile>?
> 
> Fred's response was:
> "  I expect we'll be making the package in site-packages an extension
> provider for the xml package in the standard library.  I'm planning to
> discuss this issue at today's PythonLabs meeting." 

I remember our group discussion about this.  What's currently
implemented is what we decided there, based upon (Fred's
representation of) what the XML-sig wanted.  So you don't like this
either, right?

I believe there are two conflicting desires here: (1) the standard XML
package by the core should be named simply "xml"; (2) you want the old
XML-sig code (which lives in a package named "xml" but installed in
site-packages) to override the core xml package.

I don't think that's possible -- at least not without a hack that's
too ugly to accept.

You might be able to get the old XML-sig code to override the core xml
package by creating a symlink named _xmlplus to it in site-packages
though.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)