Movatterモバイル変換
[0]ホーム
[Python-Dev] folding cElementTree behind ElementTree in 3.3
Eli Benderskyeliben at gmail.com
Wed Feb 8 05:46:46 CET 2012
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, inhttp://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 inthis direction should be taken with Fredrik's agreement.However, to re-focus: The initial proposal of changing *the stdlibimport facade* for xml.etree.ElementTree to use the C accelerator(_elementtree) by default. Will that somehow harm Fredrik'ssovereignty over ET? Are there any other problems hidden here? Becauseif not, it appears like a change of only a few lines of code couldprovide a significantly better XML processing experience in 3.3 for alot of users (and save some keystrokes for the ones who already knowto look for cElementTree).Eli
More information about the Python-Devmailing list
[8]ページ先頭