> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4