[XML-SIG] Re: saxlib 1.0beta

[Fredrik Lundh]

>>         Let me get your proposal clear; you're suggesting that we drop
>> having a driver for using xmllib, and just use xmlproc or Expat,
>> right?  
>
>No. I guess I'm suggesting we just drop xmllib. Turn it into a wrapper for
>xmlproc unless it is faster or otherwise better as it is. My point is that
>we should ship xmlproc for the DTD stuff, so once we do that, what's the
>point of xmllib anymore? 

fwiw, we're in the process of releasing our sgmllib/xmllib accelerator.
the sgml part is complete; there's still some work to do on the xml stuff.
GvR has expressed some interest in shipping this with 1.5.x or what-
ever.

>We can either think of it as a regex vs. re issue (deprecate one module
>for the other) or we could just consider xmllib a deprecated *interface*
>to xmlproc (there is probably a precedent for this, too, but I don't know
>it).

(gotta look at LarsM's SAX interface again, but if it's a direct translation
of the Java API, xmllib surely has a more pythonesque feel, IMHO).

>Yes. The DOM may also present performance problems. Python objects are a
>little heavyweight for large documents. Maybe someone will/should write a
>DOM in C. I wouldn't expect it to be that large or complicated. It would
>primarily shift the property lookup from bulky hash tables to svelte C
>code and (relatively) bulky PyObjects to C strings and pointers.

we've recently done that, and as you say, it was pretty easy.   haven't
decided yet if/how to release it to the public.

(it's not DOM on the C interface level, but I don't think adding a DOM-like
Python wrapper would be difficult).

Cheers /F
fredrik@pythonware.com
http://www.pythonware.com