RetroSearch Browse

Wed Feb 22 03:30:17 CET 2012 · https://mail.python.org/pipermail/python-dev/2012-February/116739.html

> > 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.
>

No need to be worried, Martin. If you read back in this thread you'll see
that I agree that backwards compatibility should be preserved, by making
the Element exposed from _elementtree also a type. I was simply trying to
have a discussion to better understand the use cases and implications. I
hope that's alright.

>
> 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.
>

Thanks for describing the use case. By the way, when working with ET I also
wanted to track the memory usage of the package a couple of times, which
made me lament that there's no useful memory profiler in the stdlib.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120222/8fedca7d/attachment.html>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-February/116739.html below:

[Python-Dev] folding cElementTree behind ElementTree in 3.3