Python Multiple Inheritance and MRO

3Python Multi-Inheritance: explained step by step

In Python Inheritance every child class had one parent. Python also lets a class list several parents at once. That is handy when a new kind of thing genuinely combines abilities from different places: a smartphone is both a phone and a camera.

Listing more than one parent

Put every parent in the parentheses, separated by commas: class Smartphone(Phone, Camera):. The new class receives the methods and attributes of all its parents, so nothing has to be copied.

Which parent wins?

If two parents define a method with the same name, Python has to pick one. The rule is simple: it checks the child first, then the parents from left to right, and stops at the first class that has the name.

class Camera:
    def take_photo(self):
        return "click!"

    def describe(self):
        return "a camera"

class Phone:
    def call(self, number):
        return f"calling {number}"

    def describe(self):
        return "a phone"

class Smartphone(Phone, Camera):
    pass

class PhotoPhone(Camera, Phone):
    pass

for device in (Smartphone(), PhotoPhone()):
    print(type(device).__name__, "->", device.describe(), "|", device.take_photo(), "|", device.call("555-0101"))
print([cls.__name__ for cls in Smartphone.__mro__])
print([cls.__name__ for cls in PhotoPhone.mro()])

Both classes can do everything, but describe() follows the order in the parentheses. The only difference between Smartphone and PhotoPhone is which parent is written first.

The Method Resolution Order (MRO)

Behind the scenes every class keeps the exact list of classes Python searches. It is called the method resolution order, or MRO. Smartphone.__mro__ gives it as a tuple and Smartphone.mro() gives it as a list. Whenever you call a method or read an attribute, Python walks that list from the left and uses the first class that has the name. object is always last, because every class inherits from it.

Printing the classes themselves is noisy, so print their names: [cls.__name__ for cls in Smartphone.__mro__].

The diamond problem

Things get interesting when two parents share a parent of their own. Draw the classes and you get a diamond:

        Animal
        /    \
   Swimmer  Flyer
        \    /
         Duck

Where should Animal go in the search? If Python looked in Animal before Flyer, the general Animal version of a method would hide the more specific Flyer version. Python avoids this with a rule called C3 linearisation. You do not need the algorithm, only the three promises it keeps:

1. A class always comes before its own parents.
2. Parents keep the left-to-right order you wrote them in.
3. Every class appears only once, so a shared parent such as Animal must wait until every class that inherits from it has had its turn.

For Duck(Swimmer, Flyer) that produces Duck, Swimmer, Flyer, Animal, object: one straight line with no repeats.

class Animal:
    def move(self):
        return "walks"

class Swimmer(Animal):
    def move(self):
        return "swims"

class Flyer(Animal):
    def move(self):
        return "flies"

class Duck(Swimmer, Flyer):
    pass

print([cls.__name__ for cls in Duck.__mro__])
print("A duck", Duck().move())
print("A plain flyer", Flyer().move())

super() follows the MRO, not "the parent"

So far super() has meant "my parent class". With several parents that is not quite true. super() really means "the next class after me in the MRO of the object I am working on". Inside a Duck, the class after Swimmer is Flyer, not Animal.

If every class in the diamond calls super(), the call travels down the whole MRO and each class runs exactly once. This teamwork is called cooperative inheritance:

class Animal:
    def describe(self):
        return ["an animal"]

class Swimmer(Animal):
    def describe(self):
        return ["can swim"] + super().describe()

class Flyer(Animal):
    def describe(self):
        return ["can fly"] + super().describe()

class Duck(Swimmer, Flyer):
    def describe(self):
        return ["a duck"] + super().describe()

print(", ".join(Duck().describe()))
print(", ".join(Swimmer().describe()))

Notice that Swimmer().describe() skips Flyer. A plain Swimmer has no Flyer in its MRO, so the very same Swimmer code reaches Animal there. Same code, different object, different "next class".

Cooperative __init__ and **kwargs

Because you cannot know which class comes next, you cannot hand positional arguments to "the" parent. The fix is for every __init__ to pick out the arguments it needs by name and forward the rest with **kwargs to whichever class is next:

class Animal:
    def __init__(self, name, **kwargs):
        super().__init__(**kwargs)
        self.name = name

class Swimmer(Animal):
    def __init__(self, swim_speed, **kwargs):
        super().__init__(**kwargs)
        self.swim_speed = swim_speed

class Flyer(Animal):
    def __init__(self, wingspan, **kwargs):
        super().__init__(**kwargs)
        self.wingspan = wingspan

class Duck(Swimmer, Flyer):
    pass

duck = Duck(name="Daisy", swim_speed=5, wingspan=90)
print(duck.name, duck.swim_speed, duck.wingspan)

Each class used its own keyword and passed the leftovers on. At the end of the line, Animal hands an empty **kwargs to object. A misspelled keyword would travel all the way there and raise a TypeError, which is exactly the alarm you want.

Mixins: small classes that add one skill

A mixin is a small class designed to be mixed into other classes. It does one job (turn the object into JSON, write log lines, add a timestamp), usually has no __init__ and is never meant to be used on its own. By convention its name ends in Mixin. List the mixins first and the "real" base class last, so a mixin's version of a method is found before the base class's version:

import json

class Document:
    def __init__(self, title, body):
        self.title = title
        self.body = body

class JsonMixin:
    def to_json(self):
        return json.dumps(vars(self), sort_keys=True)

class LoggingMixin:
    def log(self, message):
        print(f"[{type(self).__name__}] {message}")

class Report(JsonMixin, LoggingMixin, Document):
    pass

report = Report("Q3 sales", "Revenue grew.")
report.log("saved")
print(report.to_json())
print([cls.__name__ for cls in Report.__mro__])

Report gained two skills without writing any code of its own, and Document stayed a plain class that knows nothing about JSON or logging.

When Python says no

If the order you write the parents in breaks the three promises, Python refuses when the class is created instead of guessing. Here Broken lists a parent before its own child, which cannot be satisfied:

class Base:
    pass

class Child(Base):
    pass

try:
    class Broken(Base, Child):
        pass
except TypeError as err:
    print("TypeError:", err)

Use it with care

Multiple inheritance is a sharp tool. A reader has to keep the whole MRO in their head, and a change in one parent can quietly change which method runs. A few habits keep it safe:

• Prefer one real base class plus a few small, single-purpose mixins.
• Avoid giving different parents methods with the same name unless you mean to override them.
• If you need to print __mro__ just to understand your own code, simplify it.
• When a class merely uses another object, do not inherit at all. Composition (a car has an engine) is usually simpler, and it is the topic of the next lesson.