On Sat, 24 Aug 2013 15:57:50 +1000 Nick Coghlan <ncogh...@gmail.com> wrote: > On 24 August 2013 15:32, Stefan Behnel <stefan...@behnel.de> wrote: > > So, to put it more nicely, I think this feature was added without the > > amount of review that it needs, and now that I've given it that review, I'm > > asking for removal of the feature and a proper redesign that fits into the > > existing library. > > FWIW, it seems to me that this is something that could live in *tulip* > as an adapter between the tulip data processing APIs and the existing > ElementTree incremental parsing APIs, without needing to be added > directly to xml.etree at all.
This is not an adapter, it's a new feature that ElementTree wasn't providing before. The need to process data in a non-blocking way (not merely incremental) didn't appear with Tulip, and the fact that the API is *inspired* by Tulip doesn't make it Tulip-specific. (I'm also curious why Tulip would start providing data-processing APIs: until now, I thought it's supposed to be a networking library :-)) Furthermore, such a feature has to access implementation details of ElementTree, so it's only natural that it be provided in ElementTree. By the way, just know that Stefan tried to provide a patch that would better suit his API desires, and failed because ElementTree's current implementation makes it difficult to do so. 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. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
