This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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 <>
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.
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: <>
2013-08-25 22:10:21eli.benderskylinkissue17741 messages
2013-08-25 22:10:21eli.benderskycreate