[Python-Dev] please back out changeset f903cf864191 before alpha-2

[Eli Bendersky]

On Sat, Aug 24, 2013 at 7:33 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

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


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.

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

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130824/330077a9/attachment.html>