[XML-SIG] Finding _xmlplus in Python 2.3a2

Michael McLay mmclay@comcast.net
Sun, 02 Mar 2003 14:12:38 -0500

On Sunday 02 March 2003 11:51 am, Martijn Faassen wrote:
> Uche Ogbuji wrote:
> > I've stayed out of the _xmlplus thread because I really don't feel
> > strongly enough about the issue one way or another (nor did I when the
> > initial discussions took place).
> >
> > I understand that _xmlplus can be confusing when problems come abut, but
> > on the other hand, it would seem to me the best approach is to just try
> > to avoid those problems in the first place.  I also wonder that the
> > proposed change is too disruptive, given all the extant code that might
> > depend on the ld arrnagement.  On the flip side of that, I'm usually less
> > of a stickler for backwar compat than most if it involves a chaneg that
> > does the right thing.
> >
> > So does ditching _xmlplus even do the right thing?  Is there so little
> > discssion about this here because so few care?
> 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 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.
> This isn't just theoretical, I've seen this happen to several developers.
> These developers use PyXML but have no clue about the mysteries of
> _xmlplus, and who can blame them..

When a system admin installs PyXML over the standard xml package, it can break 
previously working applications on a system. On systems where Python is 
shared by many developers, such as starship.python.net, this type of change 
can happen with the other developers not even being aware that a change has 
taken place. This should be fixed, and a note should be added to the Python 
programming style guide to advise other developers about the problems that 
can be caused by this idiom. Perhaps it would make sense to add it to PEP 5.