> > 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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
