[Python-Dev] folding cElementTree behind ElementTree in 3.3 (original) (raw)

Eli Bendersky eliben at gmail.com
Wed Feb 22 03:30:17 CET 2012

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

More information about the Python-Dev mailing list