On Thu, 2012-07-26 at 16:03 +1000, Nick Coghlan wrote:
On 07/26/2012 09:10 AM, David Malcolm wrote:
> I did some investigating of how to do this.
>
> The replacement of xml with PyXML in the stdlib happens in
> xml/__init__.py (see e.g. /usr/lib64/python2.7/xml/__init__.py): as
> "xml" is imported, it tries to import _xmlplus, and if
> _xmlplus.version_info >= (0, 8, 4) it replaces sys.modules[__name__]
> with _xmlplus, effectively replacing "xml" with "_xmlplus".
I suggest a different tactic. Try replacing the line:
_xmlplus.__path__.extend(__path__)
with
_xmlplus.__path__[0:0] = __path__
At the moment, the replacement works as follows:
1. Both the stdlib and PyXML package dirs are on the package path
2. In the case of name clashes, prefer the PyXML version
By changing it to put the stdlib path first, you would instead set up
the following:
1. Both the stdlib and PyXML package dirs are on the package path
2. In the case of name clashes, prefer the stdlib version
(This should work, because PyXML doesn't import anything implicitly in
__init__.py)
Since Toshio reports that the current behaviour is genuinely causing
problems, you could probably make a case for this approach as an
upstream bugfix, especially if you implement it in Fedora first with no
apparent ill-effects for affected applications.
I'm nervous about this - it
seems like this would be a change of
behavior: what about code that's out there that assumes that PyXML is
preferred? We can't control the code that people install into random
virtualenvs with pip. If we unilaterally change the stdlib, that would
seem to increase the confusion.
With my proposed approach, you have to opt-in, your code can say: when I
say "xml", I really mean "xml", not "_xmlplus".
Or am I missing something?
Dave