On Sun, Apr 23, 2017 at 10:57 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:

Stephan Hoyer wrote:

In practice, CPython requires that the right operand defines a different method before it defers to it.

I'm not sure exactly what the rationale for this behaviour is,
but it's probably something along the lines that the left
method should already know how to deal with that combination
of types, and right methods are only supposed to be called
as a fallback if the left method can't handle the operands,
so calling it in that situation would be wrong.

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.

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."

In general, code should be written such that subclasses are aware of super-classes, not the other way around.

The 3.x docs don't have the "and overrides" language;

so arguably we would be changing the implementation to match
the docs.

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.

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).

More broadly: is this change significant enough that it needs a PEP?