Message196168
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:21 | eli.bendersky | set | recipients:
+ eli.bendersky, jcea, ncoghlan, scoder, jkloth, flox, python-dev |
2013-08-25 22:10:21 | eli.bendersky | set | messageid: <1377468621.32.0.788656696359.issue17741@psf.upfronthosting.co.za> |
2013-08-25 22:10:21 | eli.bendersky | link | issue17741 messages |
2013-08-25 22:10:21 | eli.bendersky | create | |
|