<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Aug 24, 2013 at 7:33 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 25 August 2013 00:26, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>


> On 25 August 2013 00:13, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
>> On Sun, 25 Aug 2013 00:03:01 +1000<br>
>> Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
>>> If Stefan's "please revert this" as lxml.etree maintainer isn't<br>
>>> enough, then I'm happy to add a "please revert this" as a core<br>
>>> committer that is confused about how and when the new tulip-inspired<br>
>>> incremental parsing API should be used in preference to the existing<br>
>>> incremental parsing API, and believes this needs to be clearly<br>
>>> resolved before adding a second way to do it<br>
>>> (especially if there's a<br>
>>> possibility of using a different implementation strategy that avoids<br>
>>> adding the second way).<br>
>><br>
>> To be clear, again: anyone who wants to "see it resolved" can take over<br>
>> the issue and handle it by themselves. I'm done with it.<br>
><br>
> OK, I'll revert it for now, then. If someone else steps up to resolve<br>
> the API duplication problem, cool, otherwise we can continue to live<br>
> without this as a standard library feature.<br>
<br>
</div>On the other hand... because other changes have been made to the<br>
module since the original commit, a simple "hg backout" is no longer<br>
possible :(<br>
<br>
Stefan - if you'd like this reverted, you're going to have to either<br>
make the alternative solution work correctly, or else craft the commit<br>
to undo the API addition.<br></blockquote><div><br><br></div><div>I'm strongly opposed to reverting 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(). Thus, it's probably OK to revert the documentation part of the commit to not mention IncrementalParser at all, making it an undocumented internal implementation detail (one of many in this module and elsewhere). However, since we're still in alpha I don't see much point to doing this change now.<br>

</div><br><div>Let's keep discussing this in the issue. Anyone interested - please make yourself nosy and any feedback on the API is welcome.<br><br>Eli<br><br></div></div><br></div></div>