[Python-Dev] please back out changeset f903cf864191 before alpha-2 (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Aug 24 16:03:01 CEST 2013

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

More information about the Python-Dev mailing list