[XML-SIG] saxlib finalization
Tue, 2 Jun 1998 10:29:07 -0400 (EDT)
Lars Marius Garshol writes:
>If there are no protests, that will be the final core SAX 1.0
>interface in Python.
I see no problems with the interface as described.
>As for the extensions, these are the new interfaces I think we should
> - ExtendedParser
> - DispatchDocHandler
>A final question: should these two last extensions be part of saxlib,
>or should we keep them separate?
I'd vote for "separate"; put them in saxexts.py or somewhere
else, but not in saxlib. No further extensions are immediately
apparent to me (assuming the simple things like a make_parser helper
function have been added), but that's not very surprising; probably
the only way to invent new extensions will be from actual use of
A side issue on packages: what's the style of import usage
that we want to encourage? That is, do we want to encourage:
class MyHandler(xml.sax.saxlib.HandlerBase): ...
from xml.sax import saxlib
from xml.sax import * # Or 'from xml.sax.saxlib ...'
class MyHandler(HandlerBase): ...
My preference is for the first, longest, form, but I'm weird. Most
people will probably use the shorter forms #2 or #3.
>I say we make the final decision on Monday 8th of June (the deadline
>is so late because I'll be offline for the 4 days prior to that
>date), and then I should be able to have a fully documented package
>out pretty soon. Hopefully we'll start seeing interesting stuff built
>on top of SAX after that.
OK. I'll try to cut a new test release of the omnibus package
tonight, with a working "make install", so we can see if it compiles
on lots of platforms.
A.M. Kuchling http://starship.skyport.net/crew/amk/
Before a war military science seems a real science, like astronomy; but after
a war it seems more like astrology.
-- Rebecca West