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

[Martijn Faassen]

Martin v. L=F6wis wrote:
> Martijn Faassen <faassen@vet.uu.nl> writes:
>=20
> > Of course, but it would also simplify matters in development and
> > deployment.=20
>=20
> It wouldn't simplify maintenance, though: Files that are now shared
> identically between Python and PyXML now must be "nearly" shared:
> Every reference to the package should then read "_xmlplus" for the
> copy of the file in PyXML, and should read "xml" for the copy of the
> file in Python.
>=20
> It would also be an ongoing source of user confusion: Should I use
> xml.dom.minidom, or _xmlplus.dom.minidom? etc.

Yes, those are two good points. I'm not sure about user confusion=20
issues; I still suspect the current scheme is far more confusing for
users. People definitely construct the wrong mental model about the
way things are set up now, and this leads to confusion and wasted time.

The nearly shared maintenance issue is a more thorny one, though.
If PyXML actually moved maintenance of modules that end up in the
Python core out of PyXML then the problem would be decreased here. This
does require updating those files only when a new major version of Python
is released (unless you sneak them in like the email package upgrade).
Would this be a large problem? As far as I'm aware eventually this is
the plan for that code anyway -- what is the thinking on that?

> > And I hope there can be some discussion of migration=20
> > strategies. You could for instance abandon the scheme in the next
> > PyXML release, keep _xmlplus of the previous one installed if it's
> > there, and point out to people that in order to use PyXML from now on
> > they have to explicitly refer to the pyxml namespace. You could even
> > provide a migration hack where people can explicitly enable pyxml to
> > be picked up in the traditional way.
>=20
> Please be aware that there is *a lot* of code out there that is still
> in use but unmaintained. We still get questions from people using code
> written for PyXML 0.5, with API that went away in PyXML 0.6. Somebody
> has to port this code, but nobody can, as the original author lost
> interest.

Yes, but changing the way packages work wouldn't much alter this,
right? Though you could say that breaking all the imports would cause
a lot of code to become unusuable with a PyXML upgrade? I don't think
that's strictly the case as one might keep an older version of PyXML
installed in parallel. In fact that might become easier if you have a
renaming (at least keeping before the renaming things installed in=20
parallel to the after the renaming stuff).

Regards,

Martijn