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

[Martijn Faassen]

Martin v. L=F6wis wrote:
> "Thomas B. Passin" <tpassin@comcast.net> writes:
>=20
> > 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 tha=
t
> > Martin is expressing (Martin, is that right?).
>=20
> I have a number of concerns, both maintainer issues, and user issues.
>=20
> 1. Maintenance issues:
>=20
>    a) proposed change is unimplementable (more precisely: the
>       straight-forward implementation is incorrect)
>       Just renaming _xmlplus can't work: you get duplicate classes, in
>       particular exception classes; if you mix them, you get
>       surprising errors. Likewise, you get multiple .dom.Node classes,
>       which is evil.
>=20
>    b) proposed change creates an ongoing maintenance problem, because
>       of nearly-shared files.

We already have this ongoing maintenance problem -- in practice now *user=
s*
of PyXML (though not the developers of PyXML) have to deal with the=20
consequences of having nearly identical but different files. In addition =
it
is not clear to users which set of files is actually in use.

The solution (which I'm not claiming is straightforward) would be to get =
rid=20
of this duplication entirely.

> 2. User issues:
>    I'm concerned that proponents of "ditch _xmlplus" only see the
>    problems that this would solve, not the problems that this would
>    create.
>    a) Users have to change tons of code.
>    b) Users will be confused which of two nearly-identical libraries th=
ey
>       should use.

Therefore we should *get rid* of the situation where we have two nearly
identical libraries. Users of PyXML/python xml package *already* are
confused with two nearly identical libraries. I've tried to show that
the _xmlhack does *not* make this invisible to users; in fact it makes it
more confusing.

I do consider a certain amount of pain to get rid of this in my opinion v=
ery
painful hack worth it, though.

Regards,

Martijn