Nick Coghlan 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. > > If this is a comment on the ElementTree API, then /F must agree with you - > iterparse was added to the API earlier this year. . . When xml.sax was added to Python, the standard approach was to create parsers that implemented the consumer pattern [1] and called methods either on the parser class itself, or on a target object. Examples include sgmllib, htmllib/formatter, and xmllib. After the discovery of efficient "pull parsing" patterns [2] and "using iterators to invert program logic" patterns (see e.g. the "anonymous blocks" thread from april this year [3], which generated a whole bunch of interesting PEPs), things have changed a bit. </F> 1) http://effbot.org/zone/consumer.htm 2) http://mail.python.org/pipermail/xml-sig/2000-May/002335.html (Paul's xml.dom.pulldom module did make it into the standard library, but it don't seem to be used much, for some unknown reason...) 3) http://mail.python.org/pipermail/python-dev/2005-April/052753.html (lots of interesting posts here)
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