Movatterモバイル変換
[0]ホーム
[Python-Dev] folding cElementTree behind ElementTree in 3.3
"Martin v. Löwis"martin at v.loewis.de
Tue Feb 21 22:47:43 CET 2012
Am 21.02.2012 11:41, schrieb Eli Bendersky:>>> On Tue, Feb 21, 2012 at 03:59, Nick Coghlan <ncoghlan at gmail.com> <mailto:ncoghlan at gmail.com>> wrote:>> On Tue, Feb 21, 2012 at 11:39 AM, Eli Bendersky <eliben at gmail.com> <mailto:eliben at gmail.com>> wrote:> > So the two choices here are either change the documentation or the C> > implementation to actually make Element a class. The first is of> course> > simpler. However, someone somewhere may have written code that> knowingly> > forces the Python implementation to be used and subclasses> Element. Such> > code will break in 3.3, so it probably makes sense to invest in making> > Element a class in the C implementation as well.>> Yeah, that's my take as well (especially since, in 3.2 and earlier,> "forcing" use of the pure Python version was just a matter of> importing ElementTree instead of cElementTree).>>> I can't fathom why someone would do it though, since bar tiny> differences (like this one) cET is just a faster ET and it's available> practically everywhere with CPython. I mean, is it really important to> be able to subclass ET.Element? What goal does it serve?Statements like this make me *extremely* worried. Please try to adopta position of much higher caution, accepting that a change is"incompatible" if there is a remote possibility that someone mightactually rely on the original behavior. Otherwise, I predict that youwill get flooded with complaints that you broke ET for no good reason.In the specific case, I tried to write a script that determines thememory usage of ET. As Element is lacking gc.get_referents support,I tried isinstance(o, Element), which failed badly.Feel free to dismiss this application as irrelevant, but I do wishthat somebody was in charge of ET who was taking backwardscompatibility as serious as Fredrik Lundh.Regards,Martin
More information about the Python-Devmailing list
[8]ページ先頭