Author eli.bendersky
Recipients eli.bendersky, flox, jcea, ncoghlan, python-dev, scoder
Date 2013-08-25.14:35:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1377441354.41.0.238206000185.issue17741@psf.upfronthosting.co.za>
In-reply-to
Content
Thanks for the effort, Stefan, but I still think IncrementalParser is worth keeping. It provides functionality that doesn't currently exist in ET, and IMHO this functionality is both important and useful.

Renaming its methods to feed & close kills the API naming inconsistency vs. XMLParser and SAX's IncrementalParser. As for future directions, having it does not add additional constrains to those that already exist because of iterparse accepting a "custom" XMLParser creates compatibility problems already.

For the latter, I think I can also beef up the documentation a bit to be more explicit (such as requiring the XMLParser provided to iterparse to derive from ET.XMLParser; otherwise, it just won't have the required _setevents).
History
Date User Action Args
2013-08-25 14:35:54eli.benderskysetrecipients: + eli.bendersky, jcea, ncoghlan, scoder, flox, python-dev
2013-08-25 14:35:54eli.benderskysetmessageid: <1377441354.41.0.238206000185.issue17741@psf.upfronthosting.co.za>
2013-08-25 14:35:54eli.benderskylinkissue17741 messages
2013-08-25 14:35:54eli.benderskycreate