Guido van Rossum wrote:
> On 12/13/05, Walter Dörwald <walter at livinglogic.de> wrote:
> > Having to define classes that conform to a certain API and registering
> > instances of those classes as callbacks with the parser doesn't look
> > that pythonic to me. An iterator API seems much more pythonic.
>
> Perhaps. Although the SAX API lets you leave a callback undefined if
> you don't have a need to handle those events; that's a bit trickier to
> do with an iterator.
Well, suppose you want to dump the text of a document.
for e in iterparse(filename):
if e.isText():
out.write(e.data)
Not tricky.
> > Also the different callbacks have different signatures.
True. With SAX I always have to look up the signatures. The iterator
yields Node-like objects in document order. I don't have to remember
signatures.
But the biggest advantage of an iterator-based API would be: when you
hit an element, you can easily pass control to a function that knows
how to parse that particular element. parsePlay() can call
parseAct(), which can call parseScene(). To do anything like that
with SAX, you have to write a bunch of dispatch code.
-j
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4