On Sun, Apr 23, 2017 at 10:57 PM, Greg Ewing <greg.ew...@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?
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/