How Does Inheritance Work in Python?

A subclass writes the name of its parent in brackets, and it inherits everything that the parent defines. The example below shows a child class that changes one method and inherits the rest.

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

    def speak(self):
        return '...'

    def describe(self):
        return self.name + ' says ' + self.speak()


class Dog(Animal):
    def speak(self):
        return 'woof'


dog = Dog('Rex')
print(dog.describe())          # Rex says woof
print(isinstance(dog, Animal)) # True
print(issubclass(Dog, Animal)) # True

Dog inherits __init__ from Animal, so you can build a Dog with a name without writing an initialiser at all. It replaces speak with its own version, and because describe was written in the parent and calls self.speak(), the parent's method uses the child's version. That behaviour has a name, and it is polymorphism. It is also why describe did not need to be replaced, even though it prints the new sound.

When a subclass needs the parent's behaviour as well as its own, super() is the way to reach it. The detail that matters is that super() inside a method refers to the next class in the current method resolution order, and not simply to the literal parent class. That is what makes it safe to use inside a mix-in, and it is why it is different from writing Parent.method(self) by hand.

When a class has several parents, Python builds one single order of classes and searches it from left to right. The super() call follows that same order, so every class in the chain contributes exactly once.

class Base:
    def hello(self):
        return 'base'


class Left(Base):
    def hello(self):
        return 'left -> ' + super().hello()


class Right(Base):
    def hello(self):
        return 'right -> ' + super().hello()


class Both(Left, Right):
    def hello(self):
        return 'both -> ' + super().hello()


print(Both().hello())
print(Both.__mro__)

The output is both -> left -> right -> base, and the method resolution order is Both, Left, Right, Base, object.

Read that result as a chain. Both.hello runs first and calls super().hello(), which continues the chain from Left. Left calls super().hello(), which continues from Right. Right calls super().hello(), which continues from Base, and Base returns the last piece. Every class in the chain contributed exactly once, and the order came from the method resolution order rather than from the order in which the classes were written.

Two things are worth pointing out. First, cooperative multiple inheritance needs every class in the chain to call super(), because that is what moves on to the next class. A class that returns without calling super() ends the chain early. Second, this diamond shape is the classic case where a naive search would call Base twice, while the method resolution order guarantees that it is called only once.

Inheritance in Python is simple. A class names one or more parents in its definition, and it inherits their attributes and their methods. A subclass can replace any method, add new ones, and extend the parent's __init__ by calling super().__init__. After that, attribute lookup follows the method resolution order, which for a single parent is simply the subclass and then the parent.

So when should you prefer composition instead? The short answer is when the relationship is a "has a" relationship rather than an "is a" relationship. A car has an engine, but a car is not a kind of engine. Composition means that one object holds a reference to another object and passes work to it, and in Python it is usually the better default.

There are four reasons composition wins. It avoids the fragile base class problem, where a change in a base class quietly breaks every subclass that depended on its internals. It keeps the parts replaceable, because a car can be given a different engine without touching the car class at all. It avoids the deep hierarchy problem, because the method resolution order and super() cooperation get complicated very quickly with several levels. And it avoids the problem of sharing state through multiple inheritance, which Python does not do for you.

That last point is the one you should be able to explain. If you inherit from two classes that both define __init__, only one of them runs automatically. The other one needs an explicit super() call, and if you get the order wrong then one initialiser silently never happens at all.

The practical rule for an interview is simple. Use inheritance for genuine "is a" relationships that share behaviour, use mix-ins for narrow and stateless behaviour, and use composition everywhere else. Python is dynamic, so you can change the design later without a large rewrite, which means you should start with the simplest thing that works.