On Wed, Feb 8, 2012 at 06:41, Fred Drake <fdrake at acm.org> wrote: > On Tue, Feb 7, 2012 at 11:31 PM, Eli Bendersky <eliben at gmail.com> wrote: >> Besides, in http://mail.python.org/pipermail/python-dev/2011-December/114812.html >> Stefan Behnel said "[...] Today, ET is *only* being maintained in the >> stdlib by Florent Xicluna [...]". Is this not true? > > I don't know. I took this to be an observation rather than a declaration > of intent by the package owner (Fredrik Lundh). > >> P.S. Would declaring that xml.etree is now independently maintained by >> pydev be a bad thing? Why? > > So long as Fredrik owns the package, I think forking it for the standard > library would be a bad thing, though not for technical reasons. Fredrik > provided his libraries for the standard library in good faith, and we still > list him as the external maintainer. Until *that* changes, forking would > be inappropriate. I'd much rather see a discussion with Fredrik about the > future maintenance plan for ElementTree and cElementTree. > Yes, I realize this is a loaded issue and I agree that all steps in this direction should be taken with Fredrik's agreement. However, to re-focus: The initial proposal of changing *the stdlib import facade* for xml.etree.ElementTree to use the C accelerator (_elementtree) by default. Will that somehow harm Fredrik's sovereignty over ET? Are there any other problems hidden here? Because if not, it appears like a change of only a few lines of code could provide a significantly better XML processing experience in 3.3 for a lot of users (and save some keystrokes for the ones who already know to look for cElementTree). 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