[XML-SIG] Finding _xmlplus in Python 2.3a2

[Martijn Faassen]

Martin v. L=F6wis wrote:
> Martijn Faassen <faassen@vet.uu.nl> writes:
>=20
> > > While I can sympathize with these concerns, I don't think anything =
can
> > > be done to change the situation that isn't very painful, and requir=
es
> > > more resources than I can offer.
> >=20
> > We (at Infrae) can also put in some resources if necessary.
>=20
> Thanks for the offer. I would need somebody to do all the work, and
> take all the blame, someone who won't run away once the work is done
> and the user complaints come in (for, say, atleast two years). It
> would probably best if that person would take over a few PyXML
> releases (you can't have responsibility without power).

At a present stage I cannot make that commitment..

> That is not to say that I want to withdraw from PyXML, but I feel
> really uneasy about such a change, and I cannot defend something I
> don't believe in.

I'd prefer working out some strategies that are less painful and that
we can all agree on. There seems to be some consensus at least of=20
separating the pieces already distributed with the Python core
from PyXML itself.

I imagine something like the following steps:

  * pieces of PyXML are already synced up with the Python core. Instead,
    those pieces will be maintained either in the Python core CVS or
    in a PyXML CVS separate from the PyXML distribution.

  * Newer PyXML distributions stop from overriding this code in the core.
    They only offer added functionality.

  * Either we give up the notion about putting everything under the 'xml'
    namespace, or a new mechanism is devised for extending the 'xml'
    namespace while not overriding core code. The former would have my
    preference as it'd be much simpler, and would involve a new namespace.

  * If a new top level namespace is created (such as 'pyxml'), some
    code will break. For instance 'xml.xpath' will break and users will
    have to start using 'pyxml.xpath'=20

  * the transition for developers to the pyxml namespace is not so
    painful, as the code in there will be relatively new (xpath for=20
    instance) and not so many systems are using it yet. A system can
    even be devised where a new version of PyXML can be installed in para=
llel
    with an older _xmlplus version of PyXML.

  * Eventually it may be decided to move more code from the pyxml package
    into the xml package and thus into the Python core. Python core
    requirements may need changes and API breakages to this code
    anyway, so that importing the new core code from a different location
    is the right thing to do. This is similar to the way other packages
    get adopted into the Python core.

Some of these steps are more dangerous than others, but all seem to be
reasonably doable, don't they?

Regards,

Martijn