Stefan Behnel added the comment: > it's really about turning XMLParser's "push" API for events (where the events > are pushed into the target object by the parser calling the appropriate > methods), into an iterparse style pull API where the events can be retrieved > via calls to read_events().
Sorry, but this is ignoring the fact that the target is an *inherent* part of this feature. In fact, the push API of XMLParser forms an integral part of the design. The events that are being collected are a mixture of what the XMLParser produces and what the target produces. You can't think this feature without these two parts. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17741> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com