Eli Bendersky, 10.02.2012 10:06: > On Fri, Feb 10, 2012 at 10:32, Florent wrote: >> 2012/2/10 Eli Bendersky >>>> >>> >>> 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).
+1 None of this would make the situation any worse than it currently is, but provide serious improvements to the user experience. Stefan _______________________________________________ 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