<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Apr 23, 2017 at 10:57 PM, Greg Ewing <span dir="ltr"><<a href="mailto:greg.ewing@canterbury.ac.nz" target="_blank">greg.ewing@canterbury.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">Stephan Hoyer wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In practice, CPython requires that the right operand defines a different method before it defers to it.<br>
</blockquote>
<br></span>
I'm not sure exactly what the rationale for this behaviour is,<br>
but it's probably something along the lines that the left<br>
method should already know how to deal with that combination<br>
of types, and right methods are only supposed to be called<br>
as a fallback if the left method can't handle the operands,<br>
so calling it in that situation would be wrong.<br><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></span></blockquote><div><br></div><div>Yes, this could makes sense. But in that case, why check for explicitly overridden methods on subclasses at all? I can rationalize either not treating subclasses differently or always trying subclasses first, but not the current behavior.</div><div><br></div><div>Of these two options, I prefer always trying subclasses first because I agree with the rationale in the docs: "This behavior allows subclasses to override their ancestors’ operations."</div><div><br></div><div>In general, code should be written such that subclasses are aware of super-classes, not the other way around.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The 3.x docs don't have the "and overrides" language;<br>
</blockquote>
<br></span>
so arguably we would be changing the implementation to match<br>
the docs.<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Based on the change in the documentation between 2.x and 3.x, I wonder if this is something that someone intended to clean up as part of Python 3000 but never got around to. I would love to hear from anyone familiar with the historical context here.</div><div><br></div><div>Nonetheless, at this point the behavior has been around for quite some time. Almost assuredly, there is *someone* relying on this feature/bug, though probably unintentionally. So I would also love to hear from anyone who knows of code that this change would actually break (as opposed to fix and/or allow for removing redundant methods).</div><div><br></div><div>More broadly: is this change significant enough that it needs a PEP?</div></div></div></div>