FEEDBACK WANTED: Type/class unification

[Guido van Rossum]

Duncan Booth <duncan at NOSPAMrcp.co.uk> writes:

> Guido van Rossum <guido at python.org> wrote in news:cp66cd12yp.fsf at cj20424-
> a.reston1.va.home.com:
> 
> > Any questions, don't hesitate to ask.
> 
> I have a question, or perhaps an observation about the new rules for 
> resolving diamond inheritance.
> 
> Given a class hierarchy such as:
> class A: pass
> class B(A):
>    def save(self): pass
> class C(A):
>    def save(self): pass
> class D(B, C):
>    def foo(self):
>        self.save() # Calls B.save
> 
> Now, if I add the following code:
> class E(B): pass
> class F(D, E): pass
> 
> f = F()
> f.foo()
> 
> My understanding of the new rules is that calling f.foo() will result in a 
> call to C.save instead of B.save (or in other words, any class that depends 
> on the search order for base classes may find this order mysteriously 
> changing if it itself is subclassed).
> 
> Is my understanding correct? Does it matter? Something similar already 
> happens in existing Python programs (define class F(C, D) and you get the 
> same effect), but previously you were less likely to encounter diamond 
> inheritance.

Correct.  There's a missing section in PEP and tutorial on
"cooperation", a generalization of a "super" call that allows you to
spell "call the next method in the chain" without naming its class
explicitly.  No time to explain that now.

--Guido van Rossum (home page: http://www.python.org/~guido/)