On Tue, Feb 21, 2012 at 11:39 AM, Eli Bendersky <eliben@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?
">

(original) (raw)



On Tue, Feb 21, 2012 at 03:59, Nick Coghlan <ncoghlan@gmail.com> wrote:

On Tue, Feb 21, 2012 at 11:39 AM, Eli Bendersky <eliben@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?


Eli