Stefan Behnel added the comment: > That means the patch could be simplified to just removing the root > attribute without changing the result of calling close().
Absolutely. Returning the parse result from close() would still make it both more consistent and easier to use (also from within iterparse()), but I agree that that's more of a feature. If the goal is really just to get the bare minimum API out that allows future extensions without introducing future consistency issues, then I'm ok with that change, too. However, note that the next lxml release will almost certainly have been out for a while when Py3.4 finally lands (I'm currently planning the release for next month, maybe early November), which means that the complete, well integrated API, including target support for iterparse() etc., will already have an established, publicly available implementation when Py3.4 comes out. If ElementTree wants to have a word in the final design of this feature, and wants to avoid introducing deliberate incompatibilities in the future, then I'd prefer finishing up this discussion before the next lxml release gets into beta state. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18990> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com