[XML-SIG] Finding _xmlplus in Python 2.3a2

[Jeremy Kloth]

On Sunday 02 March 2003 03:11 pm, Martijn Faassen wrote:
> 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.

Funny, I thought this was referring to PyXML breaking Python APIs.  The Python 
APIs are well documented.

> > 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.

I guess I'm a little hardened from this.  We develop and test for Python 
versions 2.1, 2.2 and 2.3 plus with and without PyXML, so it has become 
second nature to always ask for Python version and PyXML version when bugs 
are reported.

> 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. :)

I bring up the bug reporting simply because I don't recall anyone reporting 
that PyXML broke their Python installation until now.  The cases you mention 
are abstract, but without concrete details, I cannot reply otherwise.

I don't mean to sound uncaring, I am simply trying to improve PyXML.

Jeremy Kloth