[XML-SIG] Re: Finding _xmlplus in Python 2.3a2

[Martijn Faassen]

Thomas B. Passin wrote:
> 1) An easy, definitive way to determine whether I am using the _xmlplus
> stuff or the standard stuff, and
> 2) A convenient way to force the use of the library code that I want, in
> case the automatic machinery should disagree.

That would definitely help. Currently the problem is that _xmlplus is
supposed to be an implementation detail, except one suddenly needs to know
exactly what is going on when an error occurs.

Mental models of developers (I discussed this with a coworker today who
went through this experience) seem to go through the following stages:

  * no clue that importing from xml involves PyXML in any way. Impression
    something is odd as various platforms display different behaviors.

  * Installing PyXML adds new functionality to the 'xml' core namespace.
    The original stuff defined by the core library is still managed by
    the core library however. Hey, installing/upgrading PyXML broke my
    stuff that depends on the core library, that's odd? What's _xmlplus?

  * Okay, so _xmlplus is from PyXML, and it mysteriously gets integrated
    with the 'xml' package somehow, displaying somewhat unpredictable
    interactions.

  * Finding out (in his case getting told by me and looking at the code)
    that PyXML takes over everything, depending on its version and Python's
    version.

Anyway, one definitely needs to know this if one uses PyXML a lot. Perhaps
others have had similar learning experiences?

> I realize that we do not want to mix-and-match parts of the standard library
> with parts of PyXML, and perhaps that is one of the main concerns that
> Martin is expressing (Martin, is that right?).  But if we override, say,
> expat with our own version and it does not behave the same way as the
> standard library, not only will we cause confusion but Python itself will
> get a bad name very quickly - users will not care that only PyXML causes
> these troubles, they will blame Python generally.

At the sprint before EuroPython last summer I discovered that on
my machine I could not import expat from a certain location from 
Python 2.1 but could from Python 2.2, but on someone else's machine it
was the other way around, or something. And then installing PyXML also
changed the behavior in some different way. I forget the details, but
it was pretty funny though of course also frustrating. :)

Of course this was because some code was importing expat from non-canonical 
locations. Anything that can go confused with expat will go confused
with it. :)

> I do not think that any of the alternative proposals so far have discussed
> the mix-and-match issue sufficiently.  The current approach  handles it well
> except for breakages caused by bugs or API changes.  Martijn, would you care
> to talk about this issue some more from your point of view?

I'd say that a straightforward import structure even though it would
provide two potential places to import the 'same' thing from is still
more helpful than the current situation.

One way one could solve it is by moving stuff from PyXML that are already
inside the Python core. That may not be desirable as development is still
ongoing, but surely some things are stable enough by now to stop 
maintaining as part of PyXML?

Another possibility would be to issue warnings if you import something
from the core Python library while a newer PyXML version is installed.
Not ideal as you'd get them during deployment, but might point people in the
right direction... I guess here finding out what is installed and
changing imports accordingly in dynamic fashion might help, but that would put
the burden on the application programmer, which isn't a good idea
either (see expat).

Regards,

Martijn