On Fri, Feb 10, 2012 at 10:32, Florent <florent.xicluna at gmail.com> wrote: > 2012/2/10 Eli Bendersky <eliben at gmail.com> >> > >> >> Thanks for the input, Florent. So, to paraphrase, there already are >> code changes in the stdlib version of ET/cET which are not upstream. >> You made it explicit about the tests, so the question is only left for >> the modules themselves. Is that right? >> > > The port of ElementTree to Python 3000 was done in the standard > library only. The work was done back in 2006, 2007 and 2008. > There was never a public version of ElementTree for Python 3 outside > of the standard library. > It is already a significant change from the upstream branch (many > changes in the C extension code). > > Then when I enforced the same test suite for both implementation, I > have fixed many things in the C extension module too. To my knowledge, > these fixes were not included upstream. > > Since two years, there was regular maintenance of the package in the > standard library, but none of the patch were integrated upstream. > Folks, with this in mind, can we just acknowledge that the stdlib ElementTree is de-facto forked from Fredrik Lundh's official releases and get on with our lives? Note the code review discussion here - http://codereview.appspot.com/207048/show - where Fredrik Lundh more or less acknowledges this fact and shows no real objections to it. By "get on with our lives" I mean keep fixing problems in ElementTree inside stdlib, as well as work on exposing the C implementation behind the ElementTree API by default, falling back on the Python API (and being true to PEP 399). Eli
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4