MRO and multiple inheritance: C3, the diamond, and where super() really goes

Base: every class has a list its methods are looked up in

When you write obj.greet(), Python looks for greet not “somewhere in the hierarchy” but along a specific list of classes, in order, and takes the first match. The list sits on the class in the __mro__ attribute — the method resolution order.

Under single inheritance it is obvious:

class Base:
    def greet(self):
        return ["Base"]
 
class Left(Base):
    def greet(self):
        return ["Left"] + super().greet()
 
print(Left.__mro__)   # (Left, Base, object)

The class, its parent, the parent's parent — and object at the end, which everything inherits from. The Junior-level answer to “what is the MRO” is exactly this: it is the order in which Python looks an attribute up across the classes of a hierarchy; you can see it in Class.__mro__.

The question gets interesting when there is more than one parent, and especially when they share an ancestor — a diamond.

Mechanism 1: C3 — a merge with one rule

Intuition says “left to right, depth first”: first the whole Left branch with its ancestors, then the whole Right branch. For the diamond that gives D, Left, Base, Right, Base — and Base's method would win over Right's. Python does not do that:

class Right(Base):
    def greet(self):
        return ["Right"] + super().greet()
 
class D(Left, Right):
    def greet(self):
        return ["D"] + super().greet()
 
print([c.__name__ for c in D.__mro__])
# ['D', 'Left', 'Right', 'Base', 'object']

The common ancestor Base went to the tail, after both of its descendants. Where that comes from is easiest to see by hand. C3 merges several lists: the parents' orders — Left, Base, object for Left and Right, Base, object for Right — and the list of bases itself, Left, Right. There is one rule: take the head of the first list if it is not in the tail of any other list; otherwise try the head of the next one. The class taken is struck out of every list, and the step repeats.

The script bench/mro/order.py does exactly that, prints the merge step by step and checks the result against the interpreter's __mro__ — it matched on seven hierarchies out of seven:

1) C3 step by step: class D(Left, Right), common ancestor Base
   step 1: [Left Base object]  [Right Base object]  [Left Right]  ->  take Left
   step 2: [Base object]  [Right Base object]  [Right]  ->  take Right
   step 3: [Base object]  [Base object]  ->  take Base
   step 4: [object]  [object]  ->  take object
   by hand:         ['D', 'Left', 'Right', 'Base', 'object']
   D.__mro__:       ['D', 'Left', 'Right', 'Base', 'object']

   hand-written C3 matched __mro__ on 7 hierarchies of 7

The whole diamond is decided at the second step. Left's list comes first, and its head is now Base — but Base sits in the tail of Right's list. It cannot be taken until Right is. That is how the rule expresses what the order must satisfy: a class comes before its ancestors (hence Base after both descendants) and the order of the bases in the declaration is kept (hence Left before Right).

Formally, the documentation writes the same thing in one line:

And the merge by the very rule carried out by hand above:

This strictness has a name — monotonicity: if C1 comes before C2 in a class's order, the same holds in the order of every subclass. Adding a subclass cannot accidentally reorder the methods of its ancestors.

Mechanism 2: when there is no order, there is no class

The merge does not always succeed. Two classes with the opposite order of the same bases — and at some step there is no good head:

2) when there is no order
   class Impossible(XY, YX) -> TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y
   class Backwards(Base, Left) -> TypeError: Cannot create a consistent method resolution order (MRO) for bases Base, Left
   merge by hand for Impossible(XY, YX):
   step 1: [XY X Y object]  [YX Y X object]  [XY YX]  ->  take XY
   step 2: [X Y object]  [YX Y X object]  [YX]  ->  take YX
   step 3: no good head among X, Y

XY demands that X come before Y, YX the reverse. The head of each list lies in the tail of the other, and Python does not pick a “reasonable” option — it refuses: it is impossible to construct the merge, Python 2.3 will refuse to create the class C and will raise an exception.

The second example is shorter and looks innocent: class Backwards(Base, Left). An ancestor is declared before its own descendant — and C3 requires the descendant to come before the ancestor. The fix is to swap the bases.

What matters is when this happens: when the class statement runs, that is, when the module is imported. It never gets as far as a method call — the module will not load.

Mechanism 3: super() is the next in the instance's MRO, not the parent

The familiar phrasing is “super() calls the parent's method.” The documentation says something else:

“After” in which list? In the MRO of the object whose method was called, not of the class where super() is written. The precise wording is this: super(Left, obj) returns neither a class nor a call but a proxy — an object through which attribute lookup goes along type(obj).__mro__, starting with the class after Left. super() itself calls nothing: the call is the .greet() on the method found through it. The short “super() goes to the next in the instance's MRO” is a compressed form of this formula. That is what the diamond's behaviour is made of:

3) where super() inside Left.greet goes
   Left().greet()  -> ['Left', 'Base']
   D().greet()     -> ['D', 'Left', 'Right', 'Base']

Left.greet is written once. For a Left instance, the next after Left is Base. For a D instance, the next after Left is Right, which Left does not inherit and knows nothing about. Each method in the diamond ran exactly once, Base at the very end. That is a guarantee of the cooperative chain, not of the language: it holds as long as all its participants call super(). It is why super() is built this way: calling the parent by name would run Base twice, once from each branch.

The flip side is that the chain relies on everyone calling super(). All it takes is one class that does not call it:

4) one class does not call super()
   Broken.__mro__:  ['Broken', 'QuietLeft', 'Right', 'Base', 'object']
   Broken().greet() -> ['Broken', 'QuietLeft']

Right and Base are in the MRO but never ran. No error, no warning: the chain simply ended at QuietLeft. For Python this is not an error but an ordinary method — and at the end of a chain it is exactly the intent: Base.greet here does not call super(), and the chain ends there. It becomes a bug when the hierarchy is meant to be cooperative and a class in its middle drops out of the contract: if Right.__init__ opened a connection or registered the object, that did not happen.

A cooperative __init__

For __init__ this gives a practical rule. No class in the chain knows what comes after it — so none knows what arguments the next one needs. The documentation states the requirement like this:

In practice that means keyword arguments: each class takes its own and passes the rest along.

class Named:
    def __init__(self, *, name, **rest):
        self.name = name
        super().__init__(**rest)
 
class Sized:
    def __init__(self, *, size, **rest):
        self.size = size
        super().__init__(**rest)
 
class Item(Named, Sized):
    pass

5) cooperative __init__: each takes its own, passes the rest on
   Item.__mro__: ['Item', 'Named', 'Sized', 'object']
   Item(name='box', size=3) -> name='box', size=3
   the extra argument colour reached object -> TypeError: object.__init__() takes exactly one argument (the instance to initialize)

The last line is useful, not annoying: an argument nobody took reaches object.__init__ and fails. A typo in an argument name is not swallowed silently.

Deeper: how super() knows the class, and what a long MRO costs

super() with no arguments is not magic but a cell. Two levels are worth telling apart here. The language contract, set by PEP 3135: super() with no arguments works in a function declared in a class body and takes that class. How exactly that is done is a CPython implementation detail, and the run shows it: the compiler puts a hidden free variable __class__ into such a function — if the function uses super() or __class__. The PEP puts it more broadly: Every function will have a cell named class that contains the class object that the function is defined in.

6) super() with no arguments: the __class__ cell
   Left.greet.__code__.co_freevars: ('__class__',)
   cell contents: Left
   method without super() or __class__, co_freevars: ()
   a function declared outside the class -> RuntimeError: super(): __class__ cell not found

co_freevars and the cell itself are what CPython shows, not a promise of the language; code should rely on the contract. From it comes super()'s first argument: the class the method is written in. The second is self. The MRO is taken from type(self), and the search starts after __class__. The same fact gives the limitation: a function declared outside and attached to the class later has no cell, and super() with no arguments fails in it. There you write the explicit form super(Left, self).

The length of the MRO barely affects a repeated call. A lookup along the list of classes is linear, and without the cache that shows: each level adds 3.31 ns on 3.13.7, and at length 51 an access costs 180.8 ns. But a type has an attribute cache: it answers a repeated access without walking the list at all.

PY 3.13.7 | best of 100 interleaved rounds of 20000 accesses

  __mro__ length    hot cache     invalidated     (cost of assignment)
              2        10.8 ns          18.7 ns               26.7 ns
              6        10.9 ns          29.2 ns               27.4 ns
             21        11.0 ns          87.4 ns               26.8 ns
             51        11.9 ns         180.8 ns               26.8 ns

  per MRO level without cache: +3.31 ns
  per MRO level with cache:    +0.02 ns
  at length 51: 181 ns without cache, 12 ns with

The cache is invalidated by assigning to the class — which is why the comparison invalidates it on purpose on every iteration. In ordinary code classes do not change after import, and the left column is what applies. The cache is covered in detail in the article on what happens on o.x.

How to answer in an interview

Short answer: the MRO is the order in which Python looks an attribute up across the classes of a hierarchy; it lives in Class.__mro__ and is built by the C3 algorithm. C3 puts a class before its ancestors and keeps the order of the bases, so in the diamond D(Left, Right) the common ancestor goes to the tail: D, Left, Right, Base, object. And super() is a proxy: lookup through it goes along the instance's MRO, starting after the class where the method is written, and that is not necessarily the parent.

That is enough to answer correctly. Beyond it is what you add if the interviewer digs.

If the interviewer digs deeper

Show the diamond and two outputs of the same method: for a Left instance its super() goes to Base, for a D instance to Right. It is one line of code and the most convincing proof that “super is the parent” is wrong. The consequence follows: in a cooperative hierarchy everyone calls super(), and arguments are passed as keywords with **rest, because the next in the chain is not known in advance. Then each method in the chain runs exactly once — a property of that contract, not a rule of Python.

About the refusal, be precise: TypeError: Cannot create a consistent method resolution order arises when the class is defined, that is, on import, for example because an ancestor is declared before its descendant — class C(Base, Child). The fix is to swap the bases.

And if cost comes up — in CPython the length of the MRO barely affects a repeated call: the hot type attribute cache answers in 10.8–11.9 ns for lengths from 2 to 51 (3.13.7). The linear growth, 3.31 ns per level, appears only when the cache is invalidated by assigning to the class.

Next they ask

Common misconceptions

Version history

Practice

Two exercises. Answer first, then check against the real output: in both, the correct answer comes from a run of the script rather than being assigned.

class Base:
  def hello(self):
      print("Base")


class A(Base):
  def hello(self):
      print("A")
      super().hello()


class B(Base):
  def hello(self):
      print("B")
      super().hello()


class C(A, B):
  pass


C().hello()

A
B
Base

A
Base

A
Base
B
Base

B
A
Base

Check yourself

How it was measured

The numbers in this lesson come from these scripts. Each one opens right from here — together with the record of its run: what it ran on, what came out, and with what spread.

• bench/mro/order.py
• bench/mro/practice.py
• bench/attr-lookup/mro_cache.py
• bench/attr-lookup/mro_override.py