What Is the MRO in Multiple Inheritance?

Every Python class has a method resolution order, which is the list of classes that the interpreter searches when it looks for an attribute. You can look at it directly with the __mro__ attribute.

class A:
    def name(self):
        return 'A'


class B(A):
    def name(self):
        return 'B'


class C(A):
    def name(self):
        return 'C'


class D(B, C):
    pass


print(D.__mro__)
print(D().name())      # B

The method resolution order is D, B, C, A, object. The search starts at D, finds nothing there, moves on to B, and finds name there. So the version from B wins, even though C also defines it.

The rule that produces this order is that the search is depth-first and from left to right, with the extra condition that no class may appear twice. A depth-first search from D would give you D, B, A, C, but A is already in the list at that point. So when the search reaches C and tries to add A, A is taken out of that position and placed after C instead. The result is the linearisation shown above.

Two more things are worth noticing. The order of the base classes in the definition matters, because writing class D(C, B) would give the opposite result and C would win. And A appears after both B and C rather than being visited twice, which is what stops the shared ancestor from being searched in two separate branches.

The method resolution order is the ordered list of classes that Python searches when it cannot find an attribute on the instance or on the class of the instance. Every class has one, and you can read it with Class.__mro__. It exists because a class can have several ancestors, and something has to decide which version of a method runs.

Python computes that order with C3 linearisation, which is the same algorithm that some other languages use for a similar feature. C3 takes the direct base classes of the class together with their own method resolution orders, and it merges them so that three rules all hold. Every class comes before its own subclasses. The order of the base classes that you wrote is respected. And no class appears twice in the result.

Why this matters is that C3 is stricter than a naive depth-first search. A naive search would visit A twice in a diamond shape, and that would run the shared ancestor's initialiser or its method two times. C3 flattens the diamond into one single chain, so every class appears exactly once, and a super() chain walks that chain in order and calls every class's contribution exactly once.

The practical consequences for an interview are these. The order of the base classes in the class statement decides who wins, and it is not simply left to right, because the leftmost base's own method resolution order is merged in first. C3 can also refuse to produce an order at all, and it raises a TypeError when the class is created if the rules conflict. That is a good thing, because it means a broken hierarchy is caught when the class is defined rather than much later when some method is called.

The practical advice is the same as it is for inheritance in general. Multiple inheritance is powerful for mix-ins that add one narrow piece of behaviour, and it is rarely the right choice for concrete base classes that both hold state.