[XML-SIG] saxlib finalization

[Andrew Kuchling]

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
>have: 
>
> - 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
saxlib.

	A side issue on packages: what's the style of import usage
that we want to encourage?  That is, do we want to encourage:

import xml.sax.saxlib
class MyHandler(xml.sax.saxlib.HandlerBase): ...

or:

from xml.sax import saxlib
class MyHandler(saxlib.HandlerBase):

or even:

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