[XML-SIG] Python 1.6 XML APIs

[Greg Stein]

On Wed, Jun 21, 2000 at 01:58:50AM -0400, Fred L. Drake, Jr. wrote:
> 
> tpassin@home.com writes:
>  > I'm basically in favor both of his proposals and his reasoning behnd them.
>  > They sound like the kind of thing I'd want to use myself.  But I'm a little
>  > concerned that this might be rushing a bit too much, to get two pretty new
>  > systems into a new distribution in such a short time.  Especially the new
>  > API.  How could they get enough exposure and testing in time?
> 
>   My biggest concern lies in the potential bugginess of the
> implementation; I expect Paul knows more about XML & actually applying
> it than most of us (though possibly not all), and has sufficient
> experience that he can craft a solid API.  If the code he's talking
> about is stuff that he's been using a while, I expect its well tested
> in practice.
>   On the other hand, getting anything new documented in time will be
> difficult!  ;)

qp_xml is solid (it is used by my davlib module and a number of other people
have been using it for stuff), but there are some outstanding optimizations
on deck (from Bjorn Pettersen). I'm firefighting in Apache-land right now
:-), so I haven't applied and tested the optimizations yet.

Bjorn used a StringIO object to speed up the text concatenations. I want to
try a similar trick with string.join and compare the two.

I like the API and consider it solid/done, but there have been a number of
suggestions for changes. Particularly a number of them from Laurent Szyster. 
It would behoove us to consider some of the low-hanging fruit (but only
those which don't alter the basic character/purpose of the module/API!)
before inclusion into Python.

There is no doc yet (and I have an item in the xml package's TODO).

While people's interest in the module is great and flattering, and I'd like
to see it in Python... I'm also not too sure on whether this is the right
time. On the opposing side: it is a pretty brain-dead simple module. Not
much can go wrong, and any "extra" stuff can just build on top of it.

[ Paul does give a great breakdown on the "four quadrants" and how qp_xml
  fits in there... good stuff ]

Oh: and I might suggest a name change before inclusion into Python proper :-)

Regarding the larger question: punt on including SAX in 1.6. Why? The only
parser is pyexpat (presuming xmllib is deprecated). The utility of SAX is
therefore quite minor... what else will you swap in there? Point people at
the XML distro if they want it.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/