[XML-SIG] Finding _xmlplus in Python 2.3a2

Martijn Faassen faassen@vet.uu.nl
Mon, 3 Mar 2003 11:51:48 +0100


Martin v. L=F6wis wrote:
> Martijn Faassen <faassen@vet.uu.nl> writes:
>=20
> > As I pointed out in an earlier mail, you cannot actually solve the
> > problem by fixing bugs in PyXML. Code may actually be relying on
> > bugs or misfeatures or undisclosed APIs in the core XML code, and a
> > bugfix can therefore cause application breakage.
>=20
> The same is true for any other software package. Any change in a
> package can cause applications to stop working. So if you don't want
> to risk a breakage, don't upgrade any software.
>=20
> I cannot see how this is relevant to the _xmlplus technique, though.

You don't know you're upgrading 'the software'. Again, developers=20
are not aware of the _xmlplus technique, and software may happily
depend on the Python core's xml support, and then you install=20
PyXML and the code breaks. Confusion ensues, and since _xmlplus
is supposed to be an implementation detail, it's hard to figure out
what's going on.

This is not true for software packages that don't use this technique,
i.e. the rest of the core Python library (at least I hope not!). If I use=
=20
urllib2, it's not magically going to be upgraded as soon as I install som=
e
other library.

> > So by all means fix bugs in PyXML, the main point is that if you're u=
pgrading
> > PyXML you don't expect code that depends on the core Python library t=
o be=20
> > affected at all *even by bugfixes*, if you don't know the details of =
the
> > setup.
>=20
> The same is true for any other setup. If you upgrade the system's C
> library, you don't expect Apache to stop working, if you don't know
> the details of the setup. If you upgrade Perl, you don't expect
> spamassassin to stop working, if you don't know the details of the
> setup.

If I upgrade a Python library, or install one, I don't expect the Python
core libraries to stop working. Python is quite regular in this respect,
except for PyXML. In fact, the original code is actually still there,
it's just 'turned off'. This caused developer confusion in at three
of my co-developers here at independent instances, and since I only have
three co-developers here this indicates to me something unexpected is
going on. The _xmlplus hack is not pythonic -- imports appear from
different places based on version checks, and the core library
is unexpectedly overridden completely.

> > Of course depending on bugs or undisclosed APIs is wrong, but it happ=
ens,
> > especially in the light of incomplete documentation, and breaking the=
 code in
> > what seems to be an unrelated upgrade is wrong too.
>=20
> How is that unrelated? Both provide essentially the same software (XML
> libraries for Python, in the package "xml").

It seems to be an unrelated upgrade. People don't expect their core
library imports to be rerouted if they install a Python package, so peopl=
e
may not be aware of the fine details of what happens when you upgrade PyX=
ML.
Perhaps they think that only the extra functionality gets installed and
that core functionality is still used, instead of all that inert code
sitting there all of a sudden. People build up erroneous mental models
of this. And this is *supposed* to be an implementation detail, but it's
not as it keeps hitting people in the head. For instance, I made a mistak=
e
in a previous post on the exact behavior, and I'd even seen the version
checking code in there..

Regards,

Martijn