Python Inheritance: Missing super() Breaks Migration

Every non-trivial Python application you'll ever work on — from a Django web app to a data pipeline — will involve objects that share behaviour. Maybe you're building a payment system with CreditCardPayment and PayPalPayment classes. Maybe you're modelling a vehicle fleet with Cars, Trucks, and Motorcycles. Without inheritance, you'd copy the same methods into every class, and the moment a requirement changes, you'd hunt down every copy to fix it. That's a maintenance nightmare waiting to happen.

Inheritance solves the 'copy-paste class' problem by letting one class absorb the attributes and methods of another. The parent class (also called a base or superclass) holds the shared logic. Child classes (subclasses) inherit that logic automatically and then extend or override it where they need something different. This keeps your codebase DRY — Don't Repeat Yourself — and makes adding new types trivially easy.

By the end of this article you'll understand not just the syntax of single, multilevel, and multiple inheritance, but — more importantly — you'll know when to reach for each one, what super() actually does under the hood, how Python resolves method conflicts via the MRO (Method Resolution Order), and the two most common mistakes that trip up even experienced developers. You'll also leave with concrete answers to the interview questions that catch people out.

Why Missing super() in Python Inheritance Breaks Production

In Python, inheritance is the mechanism where a child class derives behavior from a parent class. The core mechanic is the MRO (Method Resolution Order), which determines which method runs when you call self.method(). When you override a method in a child class and omit super().method(), you break the chain of delegation — the parent's logic never executes. This is not a style choice; it's a contract violation.

Python's super() returns a proxy object that follows the MRO, enabling cooperative multiple inheritance. If you skip it, you silently discard the parent's initialization, cleanup, or validation logic. In single inheritance, this often manifests as uninitialized attributes. In multiple inheritance, it can cause entire method chains to be skipped, leading to subtle state corruption that only surfaces under specific call orders.

Use inheritance when the child truly is a specialized version of the parent — not just to share code. In real systems, missing super() is a common source of bugs in ORM models, context managers, and framework base classes. Always call super().__init__() in __init__, and super().__exit__() in __exit__, unless you have a documented reason not to.

Single Inheritance — The Foundation You Need to Nail First

Single inheritance is the simplest form: one child class inherits from exactly one parent class. This is the 90% case you'll encounter in real projects.

Here's the key mental model: the child class IS-A version of the parent. A SavingsAccount IS-A BankAccount. A ElectricCar IS-A Car. If you can't truthfully say 'X is a Y', inheritance probably isn't the right tool — you might want composition instead.

When a child class inherits from a parent, it gets every method and attribute the parent defines. It can use them as-is, override them to change their behaviour, or call them via super() and then extend the result. The super() function is your link back to the parent — it lets the child say 'do everything you normally do, and then I'll add my part on top'. Never hardcode the parent class name inside the child; always use super(). If you rename the parent class later, hardcoding it will silently break your code.

# Real-world example: a generic BankAccount and a specialised SavingsAccount

class BankAccount:
    """The parent class — holds logic every bank account needs."""

    def __init__(self, owner: str, balance: float = 0.0):
        self.owner = owner
        self.balance = balance  # shared attribute every account type needs

    def deposit(self, amount: float) -> None:
        """Add funds. Validation lives here once, not in every subclass."""
        if amount <= 0:
            raise ValueError("Deposit amount must be positive.")
        self.balance += amount
        print(f"Deposited £{amount:.2f}. New balance: £{self.balance:.2f}")

    def withdraw(self, amount: float) -> None:
        """Base withdrawal — no special rules yet."""
        if amount > self.balance:
            raise ValueError("Insufficient funds.")
        self.balance -= amount
        print(f"Withdrew £{amount:.2f}. Remaining: £{self.balance:.2f}")

    def __repr__(self) -> str:
        return f"BankAccount(owner='{self.owner}', balance=£{self.balance:.2f})"


class SavingsAccount(BankAccount):  # <-- inherits from BankAccount
    """Child class — adds an interest rate and enforces a minimum balance."""

    MINIMUM_BALANCE = 100.0  # class-level rule specific to savings accounts

    def __init__(self, owner: str, balance: float = 0.0, interest_rate: float = 0.03):
        # super().__init__ calls BankAccount.__init__ so we don't duplicate that logic
        super().__init__(owner, balance)
        self.interest_rate = interest_rate  # SavingsAccount-specific attribute

    def withdraw(self, amount: float) -> None:
        """Override parent's withdraw to enforce minimum balance rule."""
        if (self.balance - amount) < self.MINIMUM_BALANCE:
            raise ValueError(
                f"Cannot go below minimum balance of £{self.MINIMUM_BALANCE:.2f}."
            )
        # Delegate the actual withdrawal logic back to the parent — DRY!
        super().withdraw(amount)

    def apply_interest(self) -> None:
        """New method that only SavingsAccount has — not on the parent."""
        interest_earned = self.balance * self.interest_rate
        self.balance += interest_earned
        print(f"Interest applied: £{interest_earned:.2f}. Balance: £{self.balance:.2f}")

    def __repr__(self) -> str:
        return (
            f"SavingsAccount(owner='{self.owner}', "
            f"balance=£{self.balance:.2f}, rate={self.interest_rate:.1%})"
        )


# --- Usage ---
account = SavingsAccount(owner="Alice", balance=500.0, interest_rate=0.05)
print(account)

account.deposit(200.0)        # inherited from BankAccount — no code duplication
account.apply_interest()      # only available on SavingsAccount
account.withdraw(100.0)       # overridden version — checks minimum balance

try:
    account.withdraw(560.0)   # this should fail — would breach minimum balance
except ValueError as error:
    print(f"Blocked: {error}")

print(account)

Multilevel and Multiple Inheritance — Power Features With Real Trade-offs

Multilevel inheritance is a chain: C inherits from B, which inherits from A. Think of it as a lineage — Grandparent → Parent → Child. This models specialisation naturally. A PremiumSavingsAccount is a kind of SavingsAccount, which is a kind of BankAccount.

Multiple inheritance is Python-specific and more controversial: a single class can inherit from more than one parent at once. This is powerful but requires caution. Python solves the 'Diamond Problem' — where two parent classes share a common grandparent — using the Method Resolution Order (MRO). Python calculates the MRO using the C3 Linearisation algorithm. You can inspect any class's MRO by calling ClassName.__mro__ or ClassName.mro(). When Python looks for a method, it walks this list left to right and uses the first match it finds.

A good real-world use for multiple inheritance is mixins — small, focused classes that add a single capability (like logging or serialisation) without representing a full 'type'. Mixins are designed to be mixed in, not instantiated on their own.

# Multilevel inheritance: Vehicle -> Car -> ElectricCar
# Multiple inheritance via a Mixin: adding GPS capability cleanly

class Vehicle:
    """Top of the chain — every vehicle has these basics."""

    def __init__(self, make: str, model: str, year: int):
        self.make = make
        self.model = model
        self.year = year

    def start_engine(self) -> str:
        return f"{self.make} {self.model} engine started."

    def __repr__(self) -> str:
        return f"{self.year} {self.make} {self.model}"


class Car(Vehicle):
    """Multilevel level 2 — a Car IS-A Vehicle with door-count logic."""

    def __init__(self, make: str, model: str, year: int, num_doors: int = 4):
        super().__init__(make, model, year)  # pass shared args up the chain
        self.num_doors = num_doors

    def honk(self) -> str:
        return "Beep beep!"


class GpsNavigationMixin:
    """
    A mixin — NOT a standalone class, no __init__ of its own.
    It adds GPS behaviour to any class that includes it.
    """

    def get_current_location(self) -> str:
        # In a real app this would call a GPS API
        return "51.5074° N, 0.1278° W (London, UK)"

    def navigate_to(self, destination: str) -> str:
        return f"Navigating to '{destination}'... Turn right in 200m."


class ElectricCar(GpsNavigationMixin, Car):
    """
    Multilevel level 3 + Multiple inheritance.
    ElectricCar IS-A Car, and also HAS GPS navigation (via mixin).
    MRO: ElectricCar -> GpsNavigationMixin -> Car -> Vehicle -> object
    """

    def __init__(self, make: str, model: str, year: int, battery_kwh: float):
        # super().__init__ here follows the MRO — it reaches Car correctly
        super().__init__(make, model, year)
        self.battery_kwh = battery_kwh
        self.charge_level = 100.0  # percentage

    def start_engine(self) -> str:
        # Override parent's method — electric cars don't have a combustion engine
        return f"{self.make} {self.model} motor silently activated. ⚡"

    def charge_status(self) -> str:
        return f"Battery: {self.charge_level:.0f}% ({self.battery_kwh} kWh capacity)"


# --- Inspect the MRO before using it ---
print("MRO:", [cls.__name__ for cls in ElectricCar.__mro__])
print()

tesla = ElectricCar(make="Tesla", model="Model 3", year=2024, battery_kwh=82.0)
print(tesla)                          # from Vehicle.__repr__
print(tesla.start_engine())           # overridden in ElectricCar
print(tesla.honk())                   # inherited from Car
print(tesla.charge_status())          # ElectricCar's own method
print(tesla.get_current_location())   # from GpsNavigationMixin
print(tesla.navigate_to("Heathrow"))  # from GpsNavigationMixin

Method Overriding and Abstract Classes — Making Inheritance Safe by Design

Overriding a method means providing a new implementation in the child class that replaces the parent's version. Python picks the child's version first because of the MRO. But here's a subtle problem: what if you want to guarantee that every subclass MUST implement a particular method? Without enforcement, a developer could create a subclass, forget to implement process_payment(), and the bug only surfaces at runtime — potentially in production.

Python's abc module (Abstract Base Classes) fixes this at class-definition time. Mark a method with @abstractmethod and Python will refuse to let you instantiate any subclass that hasn't implemented it. You get a clear TypeError immediately, not a silent failure later.

This pattern is the backbone of frameworks like Django (Model, View), SQLAlchemy (base mappers), and any plugin system. Define the contract in the abstract base class. Every concrete implementation fulfils that contract. This is the 'O' in SOLID — Open/Closed Principle: open for extension, closed for modification.

from abc import ABC, abstractmethod
from datetime import datetime


class PaymentProcessor(ABC):
    """
    Abstract base class — defines the CONTRACT for all payment processors.
    You cannot instantiate this class directly. Any subclass MUST implement
    the abstract methods or Python raises TypeError at class creation time.
    """

    def __init__(self, merchant_id: str):
        self.merchant_id = merchant_id
        self._transaction_log: list = []

    @abstractmethod
    def process_payment(self, amount: float, currency: str) -> dict:
        """
        Every payment processor must define HOW it handles a payment.
        The what (a payment happens) is the contract. The how is up to each subclass.
        """
        pass  # abstract — no body needed

    @abstractmethod
    def refund(self, transaction_id: str) -> bool:
        """Every processor must support refunds."""
        pass

    # Concrete method — shared by ALL subclasses, no override needed
    def log_transaction(self, transaction_id: str, amount: float, status: str) -> None:
        """Non-abstract: logging works the same for every processor."""
        entry = {
            "id": transaction_id,
            "amount": amount,
            "status": status,
            "timestamp": datetime.now().strftime("%Y-%m-%d %H:%M:%S"),
        }
        self._transaction_log.append(entry)
        print(f"[LOG] Transaction {transaction_id}: {status} — £{amount:.2f}")

    def get_transaction_history(self) -> list:
        return self._transaction_log


class StripeProcessor(PaymentProcessor):
    """Concrete implementation — fulfils the PaymentProcessor contract via Stripe."""

    def process_payment(self, amount: float, currency: str) -> dict:
        # In reality: call stripe.PaymentIntent.create(...)
        transaction_id = f"stripe_txn_{int(datetime.now().timestamp())}"
        print(f"Stripe: charging £{amount:.2f} {currency} via card on file...")
        self.log_transaction(transaction_id, amount, "SUCCESS")
        return {"processor": "Stripe", "transaction_id": transaction_id, "status": "SUCCESS"}

    def refund(self, transaction_id: str) -> bool:
        # In reality: call stripe.Refund.create(payment_intent=transaction_id)
        print(f"Stripe: processing refund for {transaction_id}...")
        return True


class PayPalProcessor(PaymentProcessor):
    """Different concrete implementation — same contract, completely different internals."""

    def __init__(self, merchant_id: str, client_id: str):
        super().__init__(merchant_id)      # call parent __init__ first
        self.client_id = client_id         # PayPal-specific credential

    def process_payment(self, amount: float, currency: str) -> dict:
        transaction_id = f"pp_txn_{int(datetime.now().timestamp())}"
        print(f"PayPal: initiating £{amount:.2f} {currency} order via REST API...")
        self.log_transaction(transaction_id, amount, "PENDING")
        return {"processor": "PayPal", "transaction_id": transaction_id, "status": "PENDING"}

    def refund(self, transaction_id: str) -> bool:
        print(f"PayPal: submitting refund request for {transaction_id}...")
        return True


# --- Prove the contract is enforced ---
try:
    bad_processor = PaymentProcessor(merchant_id="test")  # should fail
except TypeError as error:
    print(f"Caught expected error: {error}\n")

# --- Use the concrete classes polymorphically ---
processors: list[PaymentProcessor] = [
    StripeProcessor(merchant_id="merch_stripe_001"),
    PayPalProcessor(merchant_id="merch_pp_001", client_id="pp_client_abc"),
]

for processor in processors:
    result = processor.process_payment(amount=49.99, currency="GBP")
    print(f"Result: {result}\n")

The super() Function Deep Dive — What It Actually Does

super() is not a shortcut for "call the parent". It returns a proxy object that delegates method calls to the next class in the MRO. In single inheritance, that next class is indeed the parent. But in multiple inheritance, super() can call a sibling class — enabling cooperative multiple inheritance.

Every class that uses super() in a method should define its signature to accept kwargs when there's any chance it will be part of a diamond hierarchy. This way, each class in the chain can pass along keyword arguments it doesn't need. You'll often see this pattern: def __init__(self, kwargs): super().__init__(**kwargs). That's cooperative inheritance.

If any class in the chain breaks the chain by NOT calling super(), the cooperative model fails silently — methods of classes later in the MRO are never called. This is the most common production bug in multiple inheritance.

# Cooperative multiple inheritance: each class passes kwargs along

class LoggingMixin:
    def __init__(self, **kwargs):
        print(f"LoggingMixin.__init__ called, kwargs: {kwargs}")
        self.logged_actions = []
        super().__init__(**kwargs)

class TimestampMixin:
    def __init__(self, **kwargs):
        print(f"TimestampMixin.__init__ called, kwargs: {kwargs}")
        self.created_at = None
        super().__init__(**kwargs)

class Base:
    def __init__(self, **kwargs):
        print(f"Base.__init__ called, kwargs: {kwargs}")
        # Base is the last in the chain — no super().__init__
        pass

class MyClass(LoggingMixin, TimestampMixin, Base):
    def __init__(self, name: str, **kwargs):
        print(f"MyClass.__init__ called, name={name}, kwargs: {kwargs}")
        super().__init__(name=name, **kwargs)

obj = MyClass(name="test")
print(f"\nInstance attributes: {obj.__dict__}")
print(f"MRO: {MyClass.__mro__}")

Inheritance vs Composition — When Not to Use Inheritance

Inheritance is overused. The most common mistake is modelling a 'HAS-A' relationship with 'IS-A'. A Car has an Engine — but making Engine a parent of Car makes no semantic sense. A Car isn't an Engine. Use composition: give Car an self.engine = Engine() attribute.

Composition gives you more flexibility at runtime. You can swap the engine type (ElectricEngine vs PetrolEngine) without changing the Car class. With inheritance, you'd need to create a new subclass for each engine type. The 'favor composition over inheritance' principle exists for a reason.

Deep inheritance hierarchies (more than 2–3 levels) become brittle. A change to a grandparent can break unrelated grandchildren. Composition avoids this by keeping classes loosely coupled and individually testable. When in doubt, ask: "Will this hierarchy have more subclasses than methods?" If yes, you've probably overused inheritance.

# Composition: Car HAS-A Engine, Engine is not a parent

class Engine:
    def start(self) -> str:
        return "Engine started."

    def stop(self) -> str:
        return "Engine stopped."

class ElectricEngine(Engine):
    def start(self) -> str:
        return "Electric motor humming."

class Car:
    def __init__(self, engine: Engine):
        self.engine = engine  # composition

    def drive(self) -> str:
        return f"{self.engine.start()} Car moving."

# Runtime flexibility:
car1 = Car(engine=Engine())
car2 = Car(engine=ElectricEngine())

print(car1.drive())
print(car2.drive())

# Compare with inheritance — brittle and rigid:
class CarWithEngine(Car):  # wrong: Car IS-NOT an Engine
    pass  # what if we want PetrolEngine tomorrow? New subclass needed.

The Object Super Class — Every Mistake Inherits From Root

Every class you write in Python 3.x silently inherits from object. That's non-negotiable. This hidden root class is why __str__, __repr__, and __eq__ exist on every instance without you typing a single method. But here's where juniors burn production: they override __init__ in a child class and forget to call super().__init__(), breaking the parent's setup. The object class itself does nothing in __init__, so it's harmless for single inheritance. The danger multiplies when you inherit from multiple classes — if any intermediate class expects parameters in __init__ and you skip the chain, attributes silently become None. Your code doesn't crash immediately. It corrupts data three method calls later. Always call super().__init__(args, *kwargs) in every __init__, even when you think it's unnecessary. The only exception is when you explicitly want to break inheritance — and that decision should trigger a code review.

# io.thecodeforge
class BaseOrder:
    def __init__(self, order_id: int):
        self.order_id = order_id
        self.status = "pending"

class PriorityOrder(BaseOrder):
    def __init__(self, order_id: int, priority: str):
        # BUG: no super().__init__()
        self.priority = priority

order = PriorityOrder(1001, "high")
print(order.order_id)  # AttributeError: 'PriorityOrder' object has no attribute 'order_id'

Abstract Base Classes — Your Contract Against Runtime Chaos

If you're writing a base class and expect child classes to override specific methods, enforce it with abc.ABC and @abstractmethod. Without this, you're praying the next developer reads the docstring. Production doesn't run on prayers. When you decorate a method with @abstractmethod, Python refuses to instantiate any class that hasn't implemented that method. The error happens at instantiation time — not three hours later when an empty method returns None, corrupting a downstream calculation. This is the difference between interface inheritance (what a class promises to do) and implementation inheritance (how it does it). Use abstract base classes to define interfaces. Reserve concrete base classes for shared logic. The abc module also supports @abstractproperty and @abstractstaticmethod for older codebases, but in modern Python, prefer @abstractmethod with regular properties or classmethods. One rule: if your base class's method body contains only pass or raise NotImplementedError, convert it to an abstract base class immediately.

# io.thecodeforge
from abc import ABC, abstractmethod

class PaymentGateway(ABC):
    @abstractmethod
    def charge(self, amount: float) -> str:
        ...

class StripeGateway(PaymentGateway):
    def charge(self, amount: float) -> str:
        return f"Charged ${amount} via Stripe"

class MockGateway(PaymentGateway):
    pass  # Forgot to implement charge()

gateway = MockGateway()  # TypeError: Can't instantiate abstract class

MRO: Method Resolution Order with C3 Linearization

Python's Method Resolution Order (MRO) determines the order in which base classes are searched when executing a method. It uses the C3 linearization algorithm, which ensures a consistent and predictable order, especially in multiple inheritance scenarios. The MRO is crucial for understanding how super() works and why missing super() calls can lead to unexpected behavior.

Consider a classic diamond inheritance problem:

```python class A: def method(self): print("A.method")

class B(A): def method(self): print("B.method") super().method()

class C(A): def method(self): print("C.method") super().method()

class D(B, C): def method(self): print("D.method") super().method() ```

Here, the MRO for class D is computed as D -> B -> C -> A. The C3 algorithm ensures that each class appears after its parents and respects the order of inheritance. If super() is omitted in B or C, the chain breaks, and A.method may never be called. Understanding MRO helps debug such issues.

To view the MRO of any class, use ClassName.__mro__ or ClassName.mro(). For example, D.__mro__ returns (, , , , ).

In production, always verify MRO when designing complex hierarchies. Tools like inspect.getmro() can dynamically inspect classes. Remember: missing super() calls in any class along the MRO can silently skip important initialization or method logic, leading to subtle bugs.

class A:
    def method(self):
        print("A.method")

class B(A):
    def method(self):
        print("B.method")
        super().method()

class C(A):
    def method(self):
        print("C.method")
        super().method()

class D(B, C):
    def method(self):
        print("D.method")
        super().method()

print(D.__mro__)
d = D()
d.method()

super() with Multiple Inheritance: Cooperative Methods

In multiple inheritance, super() enables cooperative method calls, where each class in the MRO chain can contribute to a method's execution. This pattern is essential for ensuring that all parent classes are properly initialized or have their methods invoked.

Consider a logging mixin and a database class:

```python class LoggingMixin: def __init__(self, args, kwargs): print(f"LoggingMixin.__init__ called") super().__init__(args, **kwargs)

class Database: def __init__(self, args, *kwargs): print(f"Database.__init__ called") # database initialization logic

class MyService(LoggingMixin, Database): def __init__(self, args, kwargs): print(f"MyService.__init__ called") super().__init__(args, **kwargs) ```

When creating MyService(), the MRO is MyService -> LoggingMixin -> Database -> object. Each __init__ calls super(), so all three __init__ methods execute in order. If LoggingMixin omitted super().__init__(), Database.__init__ would never run, breaking the service.

Cooperative methods require that all classes in the hierarchy use super() consistently. This is especially important in frameworks like Django or SQLAlchemy, where mixins and base classes rely on super() for proper initialization.

A common pattern is to accept args, *kwargs in all cooperative methods to pass parameters along the chain. This ensures flexibility and avoids signature mismatches.

In production, enforce super() usage in mixins and base classes via code reviews or linting rules. Missing super() calls in multiple inheritance can cause silent failures that are hard to trace.

class LoggingMixin:
    def __init__(self, *args, **kwargs):
        print(f"LoggingMixin.__init__ called")
        super().__init__(*args, **kwargs)

class Database:
    def __init__(self, *args, **kwargs):
        print(f"Database.__init__ called")
        # database initialization logic

class MyService(LoggingMixin, Database):
    def __init__(self, *args, **kwargs):
        print(f"MyService.__init__ called")
        super().__init__(*args, **kwargs)

service = MyService()

Abstract Base Classes vs Protocols: Inheritance vs Duck Typing

Python offers two main ways to define interfaces: Abstract Base Classes (ABCs) and Protocols. ABCs use inheritance to enforce that subclasses implement specific methods, while Protocols rely on structural subtyping (duck typing) where any object with the required methods is considered compatible.

ABCs are defined using the abc module:

```python from abc import ABC, abstractmethod

class Shape(ABC): @abstractmethod def area(self): pass

class Circle(Shape): def __init__(self, radius): self.radius = radius def area(self): return 3.14 self.radius * 2 ```

Here, Circle must implement area(), or instantiation will fail. ABCs provide explicit contracts but require inheritance, which can be rigid.

Protocols, introduced in PEP 544 (Python 3.8+), allow duck typing with static type checking:

```python from typing import Protocol

class Drawable(Protocol): def draw(self) -> None: ...

class Circle: def draw(self): print("Drawing circle")

class Square: def draw(self): print("Drawing square")

def render(obj: Drawable): obj.draw() ```

Circle and Square don't inherit from Drawable, but they satisfy the protocol. This is more flexible and encourages composition over inheritance.

When to use ABCs vs Protocols? Use ABCs when you need to enforce a contract at runtime (e.g., in frameworks) or when you want to provide default implementations. Use Protocols for static type checking in large codebases where you want to avoid tight coupling.

In production, prefer protocols for interfaces that are used across module boundaries, as they reduce dependencies. ABCs are still valuable for base classes with shared logic.

from abc import ABC, abstractmethod
from typing import Protocol

# ABC approach
class Shape(ABC):
    @abstractmethod
    def area(self) -> float: ...

class Circle(Shape):
    def __init__(self, radius):
        self.radius = radius
    def area(self):
        return 3.14 * self.radius ** 2

# Protocol approach
class Drawable(Protocol):
    def draw(self) -> None: ...

class Square:
    def draw(self):
        print("Drawing square")

def render(obj: Drawable):
    obj.draw()

# Usage
c = Circle(5)
print(c.area())
s = Square()
render(s)