[XML-SIG] Finding _xmlplus in Python 2.3a2
Tue, 4 Mar 2003 13:02:16 +0100
Martin v. L=F6wis wrote:
> Martijn Faassen <email@example.com> writes:
> > > While I can sympathize with these concerns, I don't think anything =
> > > be done to change the situation that isn't very painful, and requir=
> > > more resources than I can offer.
> > We (at Infrae) can also put in some resources if necessary.
> 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=
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?