5

I'm trying to understand how multiple inheritance (i.e., the C3 algorithm for method resolution order) works in Python. The toy example with the classical diamond dependency below gives me results that are against my intuition.

In particular, I noticed the following:

  1. When run as-is (i.e., both A and AA have super calls to Base, then the output is: <B> <A> <AA> <Base> </Base> </AA> </A> </B>.
  2. When only the the line marked (1) is commented out (i.e., no call to Base constructor in A), then the output is <B> <A> </A> </B>.
  3. When only the the line marked (2) is commented out (i.e., no call to Base constructor in AA), then the output is <B> <A> <AA> </AA> </A> </B>.
  4. When both lines marked (1) and (2) are commented out, then the output is <B> <A> </A> </B>.

My questions are:

  • In case 1, it seems that execution is interrupted in the constructor of A before the explicit call to the Base constructor, jumps to ("recurses into") the AA constructor (as if AA would derive from A), then descends into Base, and then back out. Is this what happens? (I understand the MRO B->A->AA->Base comes from the C3 requirement that child classes be called before parent classes.)
  • In case 2, why is the constructor of AA never called, although in case 3 it is called?
  • In both cases 2 and 3, why is the Base constructor not called, despite an explicit call in the constructor of AA (case 2) / A (case 3)? (In example 1 it is called as I would expect.)

Here are the MROs of the classes:

  • Class B: (<class '__main__.B'>, <class '__main__.A'>, <class '__main__.AA'>, <class '__main__.Base'>, <type 'object'>)
  • Class A: (<class '__main__.A'>, <class '__main__.Base'>, <type 'object'>)
  • Class AA: (<class '__main__.AA'>, <class '__main__.Base'>, <type 'object'>)
  • Class Base: (<class '__main__.Base'>, <type 'object'>)

Code:

#!/usr/bin/env python # Using Python 2.7 class Base(object): def __init__(self): print '<Base>', super(Base, self).__init__() print '</Base>', class A(Base): def __init__(self): print '<A>', super(A, self).__init__() # (1) print '</A>', class AA(Base): def __init__(self): print '<AA>', super(AA, self).__init__() # (2) print '</AA>', class B(A, AA): def __init__(self): print '<B>', super(B, self).__init__() print '</B>', if __name__ == '__main__': obj = B()
Improve this question
1

3 Answers 3

Reset to default
2

You shouldn’t see super as a function call to the next “up” in the inheritance chain. Instead, when properly used, super will ensure that all functions in the MRO are called in that order. But in order for that top happen, a super call needs to be in every segment of that chain.

So if you remove the super call in either A or AA then chain is interrupted. Depending on which you remove, the chain is interrupted either at A or AA:

  • Uninterrupted (full MRO): B, A, AA, Base
  • Case 1 (without super call in A): B, A
  • Case 2 (without super call in AA); B, A, AA

So you should keep in mind to always consistently use super in all involved types for it to function properly.

If you want to learn more about super, you should check out Raymond Hettinger’s talk “Super considered super!” at this year’s PyCon. It is very well explained and also has some easy to understand examples (involving real people!).

To quote him from that talk (transcription and emphasis mine):

What’s our biggest problem with super in Python? It’s not its design. Its design I think is flawless, it’s beautiful, Guido did an extraordinary job with it.

The problem is the name, it shouldn’t have been called “super”. Why not? The answer is, if if you learn super in any other language, it doesn’t do the same as Python.

[…] What does it do in other languages? In other languages, it calls your parents. […] Inheritance, whenever you call super is about calling your parents. But Python’s does something different. It does call parents, but not your parents. When you call super, whose parents get called? It is not your ancestors, it’s your children’s ancestors.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

From the Wikipedia article you linked:

Python creates a list of classes using the C3 linearization algorithm. That algorithm enforces two constraints: children precede their parents and if a class inherits from multiple classes, they are kept in the order specified in the tuple of base classes (however in this case, some classes high in the inheritance graph may precede classes lower in the graph[8]). Thus, the method resolution order is: D, B, C, A

So in this case (i.e., in the inheritance structure of B), the super of A is AA.

Improve this answer

1 Comment

Thanks, I forgot what graph linearization actually means. In this context the MRO actually makes sense.
0

The MRO is B, A, AA, Base. What this means is that the value of super(A, self) when self is a B object is a proxy for the AA class. If you constructed an A object the same super call would return a proxy for the Base class.

All of the behaviour that is confusing you stems directly from this.

In an A object, the super(A,self).__init__() call will call Base.__init__(self), but the same call in a B object will be a call to AA.__init__(self)

Edit to add an answer to the question in your comment:

No, you cannot find the class resolved by super for the simple reason that different attributes could resolve to different classes.

For example, in your code give class AA a method foo. Now:

b = B() super(B,b).__init__() # calls A.__init__ super(B,b).foo() # calls AA.foo

The super function doesn't just find the next class in the MRO chain, it finds the next class that has the desired attribute. That's why it has to return a proxy object rather than just returning a class.

Improve this answer

3 Comments

Thanks, now it makes sense. Is there a way to get the name of the class resolved by super (for further experimentation)? I tried super(A).__class__, but this didn't yield anything useful.
@Powerfool, I updated my answer to explain why in general it doesn't make sense to refer to the 'class resolved by super'.
Thanks Duncan, I didn't consider that aspect. The complexity overhead of dynamic languages seems considerable over, e.g., virtual inheritance in C++. Also, while C3 makes sense now, I'm wondering whether the average programmer always finds this behave immediately intuitive compared to a more static mechanism such as virtual inheritance. Next I'd about performance consequences of such indirection, but at some point I should probably open a new question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.