Eli Bendersky writes:

�> I'm strongly opposed to reverting [the change to ElementTree]
�> because it cleaned up messy code duplication and actually make the
�> code size smaller. While I agree that the API of incremental parsing
�> should be given another look, IncrementalParser can also be seen as
�> an implementation detail of iterparse().

Except that its API is familiar and cleaner. �Does any current
application depend on *not* doing whatever it is that the new API does
that IncrementalParser *does* do? �If not, why not keep the API of
IncrementalParser and shim the new code in under that?

I'm having a difficulty parsing the above. Could you please re-phrase your suggestion?
�
">

(original) (raw)




On Sat, Aug 24, 2013 at 5:55 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Eli Bendersky writes:

�> I'm strongly opposed to reverting \[the change to ElementTree\]
�> because it cleaned up messy code duplication and actually make the
�> code size smaller. While I agree that the API of incremental parsing
�> should be given another look, IncrementalParser can also be seen as
�> an implementation detail of iterparse().

Except that its API is familiar and cleaner. �Does any current
application depend on \*not\* doing whatever it is that the new API does
that IncrementalParser \*does\* do? �If not, why not keep the API of
IncrementalParser and shim the new code in under that?

I'm having a difficulty parsing the above. Could you please re-phrase your suggestion?
�

�> Thus, it's probably OK to revert the documentation part of the
�> commit to not mention IncrementalParser at all,

FWIW, as somebody who can recall using ET exactly one,
IncrementalParser is what I used.


Just to be on the safe side, I want to make sure that you indeed mean IncrementalParser, which was committed 4 months ago into the Mercurial default branch (3.4) and has only seen an alpha release?


Eli