> 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.