Needed: Real-world examples for Python's Cooperative Multiple Inheritance

[John Nagle]

On 11/25/2010 5:36 PM, Raymond Hettinger wrote:
> On Nov 25, 3:38 pm, John Nagle<na... at animats.com>  wrote:
>
>>      Best practice for this is "don't do it."  Some name clashes ought
>> to simply be detected as errors, rather than being given such
>> complex semantics.
>
> That may well be true.  If a coder has enough control over the classes
> to be make sure they use super() in a way that supports cooperative
> multiple inheritance, then they have enough control to just
> rename the methods to prevent name diamond shaped name clashes.
>
> OTOH, sometimes you don't have control over the names if they
> are magic methods or standard names like close(), save(), flush(),
> __init__(), etc.

     I'd argue that a better implementation would require
that when there's a name clash, you have to specify the class
containing the name. In other words, if A is a subclass of B,
then B.foo() overrides A.foo(). But if C is a subclass of A and
B, and there's an A.foo() and a B.foo(), calling self.foo() in
C should be an error, because it's ambiguous. You should have
to specify the parent class, using "super".

     The same issue applies in the other direction.  If
A and B are subclasses of D, and A.foo() and B.foo() are
defined, and D calls self.foo(), that's an ambiguity and
should be reported.  This catches the case where two
classed both inherit from, say "threading.thread", each
expecting to have a private thread. Someone then inherits
from both classes, getting totally unexpected results when
one of the "run" methods is chosen somewhat arbitrarily.

     Detecting a clash requires machinery CPython's lookup
machinery currently lacks. That's why I wrote that the
current semantics fell out of the implementation.

     Again, this is a form of global bug - each class can
appear internally correct, but the combination of them
won't work as expected.  This is the sort of thing which
produces obscure bugs when the components come from different
sources.  Python has relatively few dark corners like this,
but this is one of them.  (Although, in practice, nobody
seems to use this stuff, so it may not matter.)

				John Nagle