<br><br><div class="gmail_quote">On Tue, Feb 21, 2012 at 03:59, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Feb 21, 2012 at 11:39 AM, Eli Bendersky <<a href="mailto:eliben@gmail.com">eliben@gmail.com</a>> wrote:<br>
> So the two choices here are either change the documentation or the C<br>
> implementation to actually make Element a class. The first is of course<br>
> simpler. However, someone somewhere may have written code that knowingly<br>
> forces the Python implementation to be used and subclasses Element. Such<br>
> code will break in 3.3, so it probably makes sense to invest in making<br>
> Element a class in the C implementation as well.<br>
<br>
</div>Yeah, that's my take as well (especially since, in 3.2 and earlier,<br>
"forcing" use of the pure Python version was just a matter of<br>
importing ElementTree instead of cElementTree).<br>
<br></blockquote></div><br>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?<br>