Michael Foord wrote: > On 15/04/2011 02:02, Greg Ewing wrote: >> Michael Foord wrote: >>> What I was suggesting is that a method not calling super shouldn't >>> stop a *sibling* method being called, but could still prevent the >>> *parent* method being called. >> There isn't necessarily a clear distinction between parents >> and siblings. >> >> class A: >> ... >> >> class B(A): >> ... >> >> class C(A, B): >> ... >> >> In C, is A a parent of B or a sibling of B? >> Its neither, as C can't exist: >>> class A: pass ... >>> class B(A): pass ... >>> class C(A,B):pass ... Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: Cannot create a consistent method resolution order (MRO) for bases B, A > For a super call in C, B is a sibling to A. For a super call in B, A is > a parent. > > With the semantics I was suggesting if C calls super, but A doesn't then > B would still get called. > A class cannot precede any of its sub-classes in an MRO, see http://en.wikipedia.org/wiki/C3_linearization If A is a "parent" (super-class) of B, then B must precede A in any MRO that contains them both. "Siblings", in the context of a single MRO are thus classes between which there is no sub-class/super-class relation. Mark.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4