[XML-SIG] Finding _xmlplus in Python 2.3a2

Martijn Faassen faassen@vet.uu.nl
Sun, 2 Mar 2003 23:11:07 +0100


Jeremy Kloth wrote:
> On Sunday 02 March 2003 09:51 am, Martijn Faassen wrote:
> > I don't know why there is so little discussion about this; perhaps because
> > everybody who could care isn't aware of the situation -- it's not like
> > it's very obvious to people, even to people who use the XML facilities.
> 
> I would think that this would mean that the situation is working quite well if 
> people aren't even aware of it.

No, they aren't aware of it and then scratch their head in surprise when
they experience problems. That's not a good situation. They are aware
of problems but are not aware of the way _xmlplus works.

> > I think ditching _xmlplus is the right thing, as it *causes* problems, it's
> > not only confusing when problems come about from some other source. It's
> > rather difficult right now; your application might be working with core
> > Python, and if you install PyXML, it breaks. Or if you upgrade it. Oddly
> > enough, you might not even be aware that an application you build depends
> > on PyXML at all (you happened to had it installed, that's all, but were
> > reading the standard library reference and a dependency on some
> > bug/undisclosed API crept in). And then you find out later.
> 
> Using undocumented APIs are, in general, prone to just such problems.

The documentation for the PyXML APIs has historically not been complete.
If I upgrade I have to test my code, but if I upgrade a seemingly unrelated
package I do not expect things to change at all. 

> It is 
> always "use at your own risk" if an API isn't documented, don't expect it to 
> stay the same between releases.  If a developer sticks with the documented 
> APIs from the Python documentation for the xml package, I don't think that 
> PyXML has ever broken them (going from memory here, so I may be wrong).

Expect when plain bugs are introduced in PyXML, which has happened, and 
this *will* break code that worked just fine with the core libraries. Now
people will say, oh, this code doesn't work, and you say, that's odd,
what Python version do you have installed? And they say 2.2, and you say,
that's really bizarre, until it turned out they have a version of PyXML
installed as well. 

That is not a good situation.

> The one issue that comes to mind however was the change to the Text node 
> constructor.

Right, I helped a developer with that (figuring out they were using the
constructor explicitly) just recently.

>  This, though, should have been only used internal to minidom as 
> was never documented in the Python docs.  Actually, the Python docs (from 
> "minidom and the DOM standard") state applications should not instaniate the 
> classes themselves but use the interfaces on the Document object.

Yes, it was a mistake to use it, but it's pretty hard to diagnose "I 
installed PyXML and now my code broke" as well.

Anyway, to each and every case I mention you can say "Oh, that's a bug in
PyXML, please report it so we can fix it" or "Oh, the developer made
a mistake". My problem is that both are hard to diagnose and happen at
unexpected times for a developer who doesn't know this implementation detail
interaction between the Python core library and PyXML, because of the way
things are set up now. So we should educate the developers and fix the
bugs, but both would be easier if we were less confused. :)

Regards,

Martijn