On Fri, Feb 10, 2012 at 10:32, Florent <florent.xicl...@gmail.com> wrote: > 2012/2/10 Eli Bendersky <eli...@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 _______________________________________________ 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