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

[Nick Coghlan]

On 24 August 2013 20:58, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Someone can take the whole thing over if they want to, change the API
> and make it more shiny or different, tweak the implementation to suit
> it better to their own aesthetic sensibilities, but please don't revert
> an useful feature unless it's based on concrete, serious issues rather
> than a platonic disagreement about design.

While "It's a useful feature" is a necessary criterion for adding
something to the standard library, it has never been a *sufficient*
criterion. There's a lot more to take into account when judging the
latter, and one of the big ones if "There should be one obvious way to
do it".

Looking at the current documentation of ElementTree sets of alarm
bells on that front, as it contains the following method descriptions
for XMLParser:

    close()
        Finishes feeding data to the parser. Returns an element structure.

    feed(data)
        Feeds data to the parser. data is encoded data.

And these for IncrementalParser:

    data_received(data)

        Feed the given bytes data to the incremental parser.

    eof_received()

        Signal the incremental parser that the data stream is terminated.

    events()

        Iterate over the events which have been encountered in the
data fed to the parser. This method yields (event, elem) pairs, where
event is a string representing the type of event (e.g. "end") and elem
is the encountered Element object. Events provided in a previous call
to events() will not be yielded again.

It is thoroughly unclear to me as a user of the module how and why one
would use the new IncrementalParser API over the existing incremental
XMLParser API. If there is some defect in the XMLParser API that
prevents it from interoperating correctly with asynchronous code, then
*that is a bug to be fixed*, rather than avoided by adding a whole new
parallel API.

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

Regards,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia