<br><br><div class="gmail_quote">On Tue, Feb 21, 2012 at 00:51, 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="HOEnZb"><div class="h5">On Tue, Feb 21, 2012 at 1:55 AM, <<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a>> wrote:<br>
>> Basically, if something is just documented as being callable without<br>
>> subclassing or instance checks being mentioned as supported in the<br>
>> docs, it can be implemented as either a type or an ordinary function,<br>
>> or pretty much any other kind of callable without being deemed an API<br>
>> change<br>
><br>
><br>
> So what would be your evaluation of<br>
><br>
> <a href="http://docs.python.org/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element" target="_blank">http://docs.python.org/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element</a><br>
><br>
> in that respect?<br>
<br>
</div></div>Completely different from the functools.partial case - with that, the<br>
docs are very careful to *never* call functools.partial a class<br>
(instead saying "returns a callable object").<br>
<br>
The ElementTree docs unambiguously call Element a class (several<br>
times), so a conforming implementation must provide it as a class<br>
(i.e. supporting use in isinstance() checks. inheritance, etc) rather<br>
than as just a callable. A factory function is not a backwards<br>
compatible replacement (sorry Eli - given those docs, I'm definitely<br>
with Martin on this one).<br></blockquote></div><br>No need to be sorry :-) I don't think my view differs from Martin's here, by the way. My point is just that this isn't a regression, since "use cElementTree" is ubiquitous advice, and the C implementation has Element as a factory function and not a class, so the documentation wasn't correct to begin with. So the documentation isn't correct for previous versions any way you look at it. There's a conflict in that it says Element is a class and also that cElementTree implements the same API.<br>
<br>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.<br>
<br>Eli<br><br><br><br><br>