On Tue, 21 Feb 2012 12:41:17 +0200 Eli Bendersky <eli...@gmail.com> wrote: > On Tue, Feb 21, 2012 at 03:59, Nick Coghlan <ncogh...@gmail.com> wrote: > > > On Tue, Feb 21, 2012 at 11:39 AM, Eli Bendersky <eli...@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?
It probably wouldn't be very difficult to make element_new() the tp_new of Element_Type, and expose that type as "Element". That would settle the issue nicely and avoid compatibility concerns :) Regards Antoine. _______________________________________________ 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
