Author eli.bendersky
Recipients eli.bendersky, flox, jcea, jkloth, ncoghlan, python-dev, scoder
Date 2013-08-25.22:10:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1377468621.32.0.788656696359.issue17741@psf.upfronthosting.co.za>
In-reply-to
Content
I actually have another idea. Since we all agree that passing a custom "parser" to iterparse is dubious, IncrementalParser does not have to do that at all. This will make it a much more future-proof API. So its signature can be:

  class xml.etree.ElementTree.IncrementalParser(events=None)

The only remaining question is how will iterparse then work based on IncrementalParser (since iterparse does accept a parser). iterparse can just set the parser on IncrementalParser after creating it - it's an internal contract that does not have to be exposed.

This will be better than the current approach in terms of future-proofing.
History
Date User Action Args
2013-08-25 22:10:21eli.benderskysetrecipients: + eli.bendersky, jcea, ncoghlan, scoder, jkloth, flox, python-dev
2013-08-25 22:10:21eli.benderskysetmessageid: <1377468621.32.0.788656696359.issue17741@psf.upfronthosting.co.za>
2013-08-25 22:10:21eli.benderskylinkissue17741 messages
2013-08-25 22:10:21eli.benderskycreate