[Python-Dev] folding cElementTree behind ElementTree in 3.3

["Martin v. Löwis"]

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 adopt
a position of much higher caution, accepting that a change is
"incompatible" if there is a remote possibility that someone might
actually rely on the original behavior. Otherwise, I predict that you
will get flooded with complaints that you broke ET for no good reason.

In the specific case, I tried to write a script that determines the
memory 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 wish
that somebody was in charge of ET who was taking backwards
compatibility as serious as Fredrik Lundh.

Regards,
Martin