← Python

OOP: Inheritance, Polymorphism, MRO

← OOP: Inheritance, Polymorphism, MRO

Select a question from the sidebar

15 questions in this topic

Question 1 / 15

How does single inheritance work in Python, and how do you use `super()`?

Single inheritance means a class inherits from one parent class. The child class gets all attributes and methods of the parent and can override or extend them.

super() returns a proxy object that delegates method calls to the parent class in the MRO. In Python 3, super() with no arguments automatically detects the class and instance. It's preferred over directly calling Parent.method(self) because it works correctly with multiple inheritance and cooperative method chains.

Key behaviors:

The child inherits all methods and attributes from the parent
The child can override methods by defining them with the same name
super().__init__() calls the parent's initializer
super() follows the MRO, not necessarily the direct parent

Pseudo Code

1. class Child(Parent): -- Child inherits from Parent
2. super().__init__() -- call parent's __init__
3. super().method() -- call parent's method
4. Override by redefining a method with the same name
5. Extend by calling super().method() then adding behavior

Code

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

    def speak(self):
        return f"{self.name} makes a sound"

    def __repr__(self):
        return f"{self.__class__.__name__}({self.name!r})"

class Dog(Animal):
    def __init__(self, name, breed):
        super().__init__(name, species="Canine")
        self.breed = breed

    def speak(self):  # override
        return f"{self.name} says Woof!"

    def fetch(self):  # new method
        return f"{self.name} fetches the ball"

class GuideDog(Dog):
    def __init__(self, name, breed, handler):
        super().__init__(name, breed)  # calls Dog.__init__
        self.handler = handler

    def speak(self):  # extend parent method
        base = super().speak()  # calls Dog.speak()
        return f"{base} (quietly)"

# Usage
dog = Dog("Rex", "Shepherd")
print(dog.speak())     # Rex says Woof!
print(dog.species)     # Canine (inherited from Animal)
print(dog.fetch())     # Rex fetches the ball

guide = GuideDog("Buddy", "Labrador", "Alice")
print(guide.speak())   # Buddy says Woof! (quietly)
print(guide.handler)   # Alice
print(guide.species)   # Canine (inherited through chain)

# isinstance checks
print(isinstance(guide, GuideDog))  # True
print(isinstance(guide, Dog))       # True
print(isinstance(guide, Animal))    # True

# super() is equivalent to:
# super(GuideDog, self) in Python 3
# It follows MRO, not just direct parent
print(GuideDog.__mro__)
# (GuideDog, Dog, Animal, object)

Rex says Woof!
Canine
Rex fetches the ball
Buddy says Woof! (quietly)
Alice
Canine
True
True
True
(<class '__main__.GuideDog'>, <class '__main__.Dog'>, <class '__main__.Animal'>, <class 'object'>)

Key Points

•Child inherits all attributes and methods from parent
•super() delegates to the next class in the MRO
•Override by redefining; extend by calling super() first
•super() with no args auto-detects class and instance in Python 3

Gotchas

•Forgetting super().__init__() means parent attributes are never set
•super() follows MRO, which may not be the direct parent in multiple inheritance
•Parent.__init__(self) works but breaks cooperative multiple inheritance

Child class inherits from parent. Override methods by redefining them. Use super() to call parent methods. super() follows MRO, not just the direct parent.

•super().__init__() calls parent initializer
•Override by redefining, extend by calling super() first

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

class Dog(Animal):
    def __init__(self, name, breed):
        super().__init__(name)
        self.breed = breed
    def speak(self):
        return f"{self.name} says Woof!"

dog = Dog("Rex", "Lab")
print(dog.speak())  # Rex says Woof!

Rex says Woof!

Forgetting super().__init__() leaves parent attributes unset

Question 2 / 15

How does multiple inheritance work in Python, and what is the diamond problem?

Python supports multiple inheritance, where a class can inherit from multiple parent classes. The diamond problem occurs when a class inherits from two classes that share a common ancestor, potentially causing ambiguity about which parent's method to use.

Python solves this using the C3 linearization algorithm to compute the MRO (Method Resolution Order). The MRO ensures:

A class comes before its parents
Parents are searched in the order they appear in the class definition
Common ancestors appear only once, at the end

super() follows the MRO, not just the direct parent. This enables cooperative multiple inheritance where each class calls super() to pass control to the next class in the MRO chain.

Pseudo Code

Diamond: D inherits from B and C, both inherit from A
  A
 / \
B   C
 \ /
  D

MRO for D: D -> B -> C -> A -> object
super() in D calls B, super() in B calls C, super() in C calls A
A.__init__ is called exactly once if all classes use super()

Code

class A:
    def __init__(self):
        print("A.__init__")
        super().__init__()

    def method(self):
        return "A"

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

    def method(self):
        return "B"

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

    def method(self):
        return "C"

class D(B, C):  # diamond inheritance
    def __init__(self):
        print("D.__init__")
        super().__init__()

# MRO resolves the diamond
print(D.__mro__)
# (D, B, C, A, object)

d = D()
# D.__init__
# B.__init__
# C.__init__
# A.__init__
# Each __init__ called exactly once!

print(d.method())  # "B" -- first in MRO after D

# Without super(), A gets called twice (broken)
class BadB(A):
    def __init__(self):
        print("BadB.__init__")
        A.__init__(self)  # explicitly calls A, not following MRO

class BadC(A):
    def __init__(self):
        print("BadC.__init__")
        A.__init__(self)  # explicitly calls A

class BadD(BadB, BadC):
    def __init__(self):
        print("BadD.__init__")
        BadB.__init__(self)
        BadC.__init__(self)

bad = BadD()
# BadD.__init__
# BadB.__init__
# A.__init__        <- first time
# BadC.__init__
# A.__init__        <- second time! BAD!

# Practical example
class JSONMixin:
    def to_json(self):
        import json
        return json.dumps(self.__dict__)

class HTMLMixin:
    def to_html(self):
        items = "".join(f"<li>{k}: {v}</li>" for k, v in self.__dict__.items())
        return f"<ul>{items}</ul>"

class User(JSONMixin, HTMLMixin):
    def __init__(self, name, email):
        self.name = name
        self.email = email

u = User("Alice", "alice@example.com")
print(u.to_json())   # {"name": "Alice", "email": "alice@example.com"}
print(u.to_html())   # <ul><li>name: Alice</li><li>email: alice@example.com</li></ul>

(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <class 'object'>)
D.__init__
B.__init__
C.__init__
A.__init__
B
BadD.__init__
BadB.__init__
A.__init__
BadC.__init__
A.__init__
{"name": "Alice", "email": "alice@example.com"}
<ul><li>name: Alice</li><li>email: alice@example.com</li></ul>

Key Points

•Python uses C3 linearization to compute MRO for diamond inheritance
•super() follows MRO ensuring each class is called once
•Direct parent calls (Parent.__init__(self)) bypass MRO and cause duplicate calls
•Order of base classes matters: class D(B, C) searches B before C

Gotchas

•All classes in the chain must use super() for cooperative inheritance to work
•Mixing super() calls with explicit Parent.method() calls breaks the chain
•If base classes have incompatible __init__ signatures, super() chains become tricky
•C3 linearization can raise TypeError if a consistent MRO cannot be computed

Multiple inheritance lets a class inherit from several parents. The diamond problem is solved by C3 linearization (MRO). Use super() everywhere to ensure each class is called exactly once.

•C3 linearization resolves diamond problem
•super() follows MRO, calling each class once

class A:
    def greet(self): return "A"

class B(A):
    def greet(self): return "B"

class C(A):
    def greet(self): return "C"

class D(B, C):
    pass

print(D.__mro__)    # D -> B -> C -> A -> object
print(D().greet())  # "B" (first in MRO)

(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <class 'object'>)
B

All classes must use super() for cooperative inheritance

Question 3 / 15

What is the MRO (Method Resolution Order) and how does C3 linearization work?

The MRO (Method Resolution Order) is the order in which Python searches base classes when looking up a method or attribute. Python uses the C3 linearization algorithm (also called C3 superclass linearization) to compute it.

C3 linearization guarantees:

Monotonicity: If class C1 comes before C2 in the MRO of a class, then C1 comes before C2 in the MRO of any subclass
Local precedence order: The order of base classes in the class definition is preserved
No duplicates: Each class appears exactly once

The algorithm merges the linearizations of parent classes while respecting both the local ordering (order in class definition) and the ordering in parent linearizations. If no consistent ordering exists, Python raises TypeError.

You can inspect the MRO using ClassName.__mro__ (tuple) or ClassName.mro() (list).

Pseudo Code

C3 linearization for class C(B1, B2, ..., BN):
L[C] = C + merge(L[B1], L[B2], ..., L[BN], [B1, B2, ..., BN])

Merge algorithm:
1. Take the head of the first list
2. If it doesn't appear in the tail of any other list, add it to result
3. Otherwise, skip to the next list and try its head
4. Repeat until all lists are empty
5. If stuck (head appears in tail of another list), raise TypeError

Code

# Simple hierarchy
class A: pass
class B(A): pass
class C(A): pass
class D(B, C): pass

print(D.__mro__)
# (<class 'D'>, <class 'B'>, <class 'C'>, <class 'A'>, <class 'object'>)

# More complex hierarchy
class O: pass
class A(O): pass
class B(O): pass
class C(O): pass
class D(A, B): pass
class E(B, C): pass
class F(D, E): pass

print(F.mro())
# [F, D, A, E, B, C, O, object]

# Inconsistent MRO -- TypeError
try:
    class X: pass
    class Y(X): pass
    class Z(X, Y):  # X before Y, but Y is subclass of X
        pass
except TypeError as e:
    print(e)
    # Cannot create a consistent method resolution order (MRO)
    # for bases X, Y

# Practical impact: which method gets called
class Base:
    def method(self):
        return "Base"

class Left(Base):
    def method(self):
        return "Left"

class Right(Base):
    def method(self):
        return "Right"

class Child(Left, Right):
    pass

print(Child().method())  # "Left" -- Left comes first in MRO
print(Child.__mro__)
# (Child, Left, Right, Base, object)

# super() follows MRO
class A:
    def method(self):
        print("A.method")

class B(A):
    def method(self):
        print("B.method")
        super().method()  # next in MRO, not necessarily A

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

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

D().method()
# D.method
# B.method  <- super() in B goes to C (next in MRO), not A!
# C.method
# A.method

(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <class 'object'>)
[<class '__main__.F'>, <class '__main__.D'>, <class '__main__.A'>, <class '__main__.E'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.O'>, <class 'object'>]
Cannot create a consistent method resolution
order (MRO) for bases X, Y
Left
(<class '__main__.Child'>, <class '__main__.Left'>, <class '__main__.Right'>, <class '__main__.Base'>, <class 'object'>)
D.method
B.method
C.method
A.method

Key Points

•MRO is computed using C3 linearization at class creation time
•Guarantees monotonicity, preserves local ordering, no duplicates
•Inspect with __mro__ (tuple) or .mro() (list)
•super() follows MRO, not the direct parent

Gotchas

•Inconsistent hierarchies raise TypeError at class creation time
•super() in class B may call class C (not A) depending on MRO of the leaf class
•Adding a base class can change the MRO of all subclasses
•class C(X, Y) where Y inherits from X is invalid -- TypeError

MRO is the order Python searches base classes for methods. C3 linearization computes it, preserving local order and preventing duplicates. Check with Class.__mro__.

•C3 ensures consistent, monotonic ordering
•__mro__ shows the computed order

class A: pass
class B(A): pass
class C(A): pass
class D(B, C): pass

print(D.__mro__)
# D -> B -> C -> A -> object

# super() follows this exact order
print(D.mro())  # same as list

(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <class 'object'>)
[<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <class 'object'>]

Inconsistent hierarchies raise TypeError at class creation

Question 4 / 15

What are abstract base classes (ABCs) and how do you use the `abc` module?

Abstract Base Classes (ABCs) define interfaces that subclasses must implement. They cannot be instantiated directly. Python's abc module provides ABC (a helper class) and @abstractmethod decorator.

When a class inherits from ABC and has abstract methods, any subclass that doesn't implement ALL abstract methods cannot be instantiated -- Python raises TypeError at instantiation time.

ABCs are useful for:

Defining contracts/interfaces that subclasses must follow
Documentation of expected interface
Runtime enforcement of the interface
Registering virtual subclasses with .register()

Python's standard library uses ABCs extensively in collections.abc (Iterable, Mapping, Sequence, etc.).

Pseudo Code

1. from abc import ABC, abstractmethod
2. class MyABC(ABC):
3.     @abstractmethod
4.     def required_method(self): ...
5. class Concrete(MyABC):
6.     def required_method(self): return 'implemented'
7. MyABC() -> TypeError (can't instantiate)
8. Concrete() -> works (all abstract methods implemented)

Code

from abc import ABC, abstractmethod

class Shape(ABC):
    @abstractmethod
    def area(self) -> float:
        """Calculate area. Must be implemented by subclasses."""
        ...

    @abstractmethod
    def perimeter(self) -> float:
        """Calculate perimeter. Must be implemented by subclasses."""
        ...

    def describe(self) -> str:
        """Concrete method -- inherited by all subclasses."""
        return f"{self.__class__.__name__}: area={self.area():.2f}, perimeter={self.perimeter():.2f}"

# Cannot instantiate ABC
try:
    s = Shape()
except TypeError as e:
    print(e)  # Can't instantiate abstract class Shape with abstract methods area, perimeter

# Must implement ALL abstract methods
class Circle(Shape):
    def __init__(self, radius: float):
        self.radius = radius

    def area(self) -> float:
        import math
        return math.pi * self.radius ** 2

    def perimeter(self) -> float:
        import math
        return 2 * math.pi * self.radius

class Rectangle(Shape):
    def __init__(self, width: float, height: float):
        self.width = width
        self.height = height

    def area(self) -> float:
        return self.width * self.height

    def perimeter(self) -> float:
        return 2 * (self.width + self.height)

c = Circle(5)
print(c.describe())  # Circle: area=78.54, perimeter=31.42

r = Rectangle(3, 4)
print(r.describe())  # Rectangle: area=12.00, perimeter=14.00

# Incomplete implementation raises TypeError
try:
    class Incomplete(Shape):
        def area(self):
            return 0
        # missing perimeter!

    Incomplete()  # TypeError
except TypeError as e:
    print(e)

# Abstract properties
class Vehicle(ABC):
    @property
    @abstractmethod
    def fuel_type(self) -> str:
        ...

class ElectricCar(Vehicle):
    @property
    def fuel_type(self) -> str:
        return "electric"

# Virtual subclass registration
class MyMapping(ABC):
    @abstractmethod
    def __getitem__(self, key): ...

MyMapping.register(dict)  # dict is now a "virtual subclass"
print(isinstance({}, MyMapping))  # True

Can't instantiate abstract class Shape without an implementation for abstract methods 'area', 'perimeter'
Circle: area=78.54, perimeter=31.42
Rectangle: area=12.00, perimeter=14.00
Can't instantiate abstract class Incomplete without an implementation for abstract method 'perimeter'
True

Key Points

•ABCs define required interfaces with @abstractmethod
•Cannot instantiate a class with unimplemented abstract methods
•Concrete methods in ABCs are inherited normally
•collections.abc provides standard ABCs (Iterable, Mapping, etc.)

Gotchas

•TypeError is raised at instantiation, not at class definition -- the incomplete class CAN be defined
•@abstractmethod must be the innermost decorator (closest to the function)
•.register() creates virtual subclasses that pass isinstance but don't actually inherit
•ABCs add overhead -- use Protocol for structural typing when you don't need enforcement

ABCs from the abc module define interfaces with @abstractmethod. Subclasses must implement all abstract methods or they can't be instantiated. ABCs can also have concrete methods.

•@abstractmethod enforces implementation in subclasses
•TypeError at instantiation if abstract methods are missing

from abc import ABC, abstractmethod

class Animal(ABC):
    @abstractmethod
    def speak(self) -> str: ...

class Dog(Animal):
    def speak(self) -> str:
        return "Woof!"

# Animal()  # TypeError: can't instantiate
print(Dog().speak())  # Woof!

Woof!

Error at instantiation time, not class definition time

Question 5 / 15

What are mixins in Python, and how do they differ from regular inheritance?

A mixin is a class that provides methods to other classes through multiple inheritance but is not meant to stand alone. Mixins add specific functionality (like serialization, logging, or comparison) without being a full parent class.

Key characteristics of mixins:

Not instantiated directly -- they're meant to be mixed into other classes
Single responsibility -- each mixin adds one specific capability
No __init__ (usually) -- they don't manage their own state
Name ends in 'Mixin' (convention) -- makes intent clear
Use super() -- for cooperative inheritance chains

Mixins are Python's answer to interfaces with default methods (Java) or traits (Scala/Rust). They're preferred over deep inheritance hierarchies because they compose horizontally.

Pseudo Code

1. Define mixin class with specific functionality
2. No __init__ (usually), no standalone use
3. class MyClass(Mixin1, Mixin2, BaseClass): ...
4. Mixins typically listed before the base class
5. Each mixin adds one concern (serialization, logging, etc.)

Code

import json

class JSONMixin:
    """Adds JSON serialization/deserialization."""
    def to_json(self) -> str:
        return json.dumps(self.__dict__, default=str)

    @classmethod
    def from_json(cls, json_str: str):
        data = json.loads(json_str)
        return cls(**data)

class ReprMixin:
    """Adds automatic __repr__ based on __dict__."""
    def __repr__(self) -> str:
        attrs = ", ".join(f"{k}={v!r}" for k, v in self.__dict__.items())
        return f"{self.__class__.__name__}({attrs})"

class ComparableMixin:
    """Adds comparison based on a 'sort_key' property."""
    def __lt__(self, other):
        if not isinstance(other, self.__class__):
            return NotImplemented
        return self.sort_key < other.sort_key

    def __eq__(self, other):
        if not isinstance(other, self.__class__):
            return NotImplemented
        return self.sort_key == other.sort_key

# Compose mixins into a concrete class
class User(JSONMixin, ReprMixin, ComparableMixin):
    def __init__(self, name: str, age: int):
        self.name = name
        self.age = age

    @property
    def sort_key(self):
        return self.age

# All mixin functionality is available
u1 = User("Alice", 30)
u2 = User("Bob", 25)

print(u1)           # User(name='Alice', age=30)  -- ReprMixin
print(u1.to_json())  # {"name": "Alice", "age": 30}  -- JSONMixin
print(u1 > u2)       # True  -- ComparableMixin

u3 = User.from_json('{"name": "Charlie", "age": 35}')
print(u3)  # User(name='Charlie', age=35)

# Cooperative mixin with super()
class LoggingMixin:
    def save(self):
        print(f"Logging: saving {self!r}")
        super().save()  # cooperative call

class PersistenceMixin:
    def save(self):
        print(f"Persisting: {self!r}")
        # End of chain -- no super().save()

class Document(LoggingMixin, PersistenceMixin, ReprMixin):
    def __init__(self, title):
        self.title = title

doc = Document("Report")
doc.save()
# Logging: saving Document(title='Report')
# Persisting: Document(title='Report')

User(name='Alice', age=30)
{"name": "Alice", "age": 30}
True
User(name='Charlie', age=35)
Logging: saving Document(title='Report')
Persisting: Document(title='Report')

Key Points

•Mixins add specific functionality without being standalone classes
•Single responsibility per mixin, no __init__ usually
•List mixins before base class: class MyClass(Mixin, Base)
•Use super() in mixins for cooperative method chains

Gotchas

•Method name conflicts between mixins can cause unexpected behavior -- check MRO
•Mixins that assume specific attributes exist may break with unexpected classes
•Too many mixins make the MRO complex and hard to debug
•super() chain order depends on the final class's MRO, not the mixin definition

Mixins are small classes that add specific functionality (serialization, logging) via multiple inheritance. They're not standalone, have no __init__, and add a single concern each.

•Single responsibility, not standalone
•List mixins before base class in inheritance

import json

class JSONMixin:
    def to_json(self):
        return json.dumps(self.__dict__)

class User(JSONMixin):
    def __init__(self, name, age):
        self.name = name
        self.age = age

print(User("Alice", 30).to_json())
# {"name": "Alice", "age": 30}

{"name": "Alice", "age": 30}

Method name conflicts resolved by MRO

Question 6 / 15

How do you override methods in Python, and what is method overriding vs overloading?

Method overriding is when a subclass provides its own implementation of a method that exists in the parent class. The child's version is called for child instances. This is a core polymorphism mechanism.

Method overloading (multiple methods with the same name but different signatures) does NOT exist in Python like it does in Java/C++. Python only keeps the last definition of a function with a given name. Instead, Python achieves similar behavior through:

Default arguments
*args and **kwargs
@functools.singledispatch for type-based dispatch
@typing.overload for type checker hints (no runtime effect)

When overriding, you can:

Completely replace the parent's implementation
Extend it by calling super().method() and adding behavior
Conditionally call the parent based on some logic

Pseudo Code

Overriding:
1. Define method in child with same name as parent
2. Child instances use child's version
3. Use super().method() to extend parent behavior

No true overloading in Python:
1. Use default args: def method(self, x, y=None)
2. Use *args/**kwargs for variable signatures
3. Use @singledispatch for type-based dispatch

Code

# Method overriding
class Logger:
    def log(self, message):
        print(f"[LOG] {message}")

class FileLogger(Logger):
    def __init__(self, filename):
        self.filename = filename

    def log(self, message):  # override
        # Extend: call parent then add behavior
        super().log(message)
        with open(self.filename, "a") as f:
            f.write(f"{message}\n")

class SilentLogger(Logger):
    def log(self, message):  # complete replacement
        pass  # do nothing

# Polymorphism in action
loggers = [Logger(), SilentLogger()]
for logger in loggers:
    logger.log("test")  # each uses its own log()

# Python does NOT have method overloading
# This just redefines the method:
class Calculator:
    def add(self, a, b):  # this gets overwritten
        return a + b

    def add(self, a, b, c):  # only this version exists
        return a + b + c

# calc.add(1, 2)  # TypeError: missing argument 'c'

# Python alternatives to overloading:

# 1. Default arguments
class Calc:
    def add(self, a, b, c=0):
        return a + b + c

# 2. @singledispatch for type-based dispatch
from functools import singledispatch

@singledispatch
def process(data):
    raise TypeError(f"Unsupported type: {type(data)}")

@process.register(str)
def _(data):
    return data.upper()

@process.register(list)
def _(data):
    return [x * 2 for x in data]

@process.register(int)
def _(data):
    return data ** 2

print(process("hello"))   # HELLO
print(process([1, 2, 3])) # [2, 4, 6]
print(process(5))         # 25

# 3. @typing.overload for type checker hints (no runtime effect)
from typing import overload

class Parser:
    @overload
    def parse(self, data: str) -> dict: ...
    @overload
    def parse(self, data: bytes) -> dict: ...

    def parse(self, data):
        if isinstance(data, bytes):
            data = data.decode("utf-8")
        import json
        return json.loads(data)

[LOG] test
HELLO
[2, 4, 6]
25

Key Points

•Overriding: child redefines parent method, child version used for child instances
•No true overloading in Python -- last definition wins
•Use default args, *args/**kwargs, or @singledispatch instead of overloading
•@typing.overload is for type checkers only, no runtime effect

Gotchas

•Defining two methods with the same name in a class: the second overwrites the first
•@singledispatch dispatches on the first argument's type only
•@typing.overload must have a concrete implementation after the overloaded signatures
•super().method() in an override may call a sibling class (not parent) in diamond inheritance

Overriding: child redefines parent method. No overloading in Python (last definition wins). Use default args, *args/**kwargs, or @singledispatch for different signatures.

•Override by redefining method in subclass
•No overloading -- use default args or singledispatch

class Animal:
    def speak(self):
        return "..."

class Dog(Animal):
    def speak(self):  # overrides Animal.speak
        return "Woof!"

class Cat(Animal):
    def speak(self):  # overrides Animal.speak
        return "Meow!"

for a in [Dog(), Cat()]:
    print(a.speak())  # Woof! then Meow! (polymorphism)

Woof!
Meow!

Two methods with same name: second overwrites first

Question 7 / 15

What is polymorphism in Python, and how does duck typing relate to it?

Polymorphism means "many forms" -- the ability to use objects of different types through a uniform interface. In Python, polymorphism works through:

Duck typing: "If it walks like a duck and quacks like a duck, it's a duck." Python doesn't check the type -- it checks whether the object supports the required operations. This is the most Pythonic form.
Method overriding: Subclasses provide different implementations of the same method.
Operator overloading: The + operator calls __add__, which behaves differently for ints, strings, and lists.

Python's duck typing means you don't need inheritance for polymorphism. Any object that implements the required methods works. This is formalized by typing.Protocol (Python 3.8+) for structural subtyping.

Pseudo Code

Duck typing:
1. Don't check type, check behavior
2. If obj has .read() method, it's file-like
3. No inheritance needed
4. Try to use the object; handle failure

Protocol (formalized duck typing):
1. Define Protocol with required methods
2. Any class implementing those methods satisfies it
3. No explicit inheritance needed

Code

# Duck typing -- no inheritance needed
class Duck:
    def quack(self):
        return "Quack!"

class Person:
    def quack(self):
        return "I'm quacking like a duck!"

class Dog:
    def bark(self):
        return "Woof!"

def make_it_quack(thing):
    """Works with anything that has a quack() method."""
    return thing.quack()

print(make_it_quack(Duck()))    # Quack!
print(make_it_quack(Person()))  # I'm quacking like a duck!
# make_it_quack(Dog())  # AttributeError: no quack()

# File-like duck typing (standard library pattern)
class StringBuffer:
    def __init__(self):
        self.data = []

    def write(self, text):
        self.data.append(text)

    def read(self):
        return "".join(self.data)

import csv
import io

# csv.writer works with anything that has .write()
buffer = StringBuffer()
writer = csv.writer(buffer)  # StringBuffer is "file-like" via duck typing
writer.writerow(["name", "age"])
writer.writerow(["Alice", 30])
print(buffer.read())  # name,age\nAlice,30\n

# Protocol -- formalized duck typing (Python 3.8+)
from typing import Protocol, runtime_checkable

@runtime_checkable
class Drawable(Protocol):
    def draw(self) -> str: ...

class Circle:
    def draw(self) -> str:
        return "Drawing circle"

class Square:
    def draw(self) -> str:
        return "Drawing square"

def render(shape: Drawable) -> str:
    return shape.draw()

print(render(Circle()))  # Drawing circle
print(render(Square()))  # Drawing square

# runtime_checkable allows isinstance checks
print(isinstance(Circle(), Drawable))  # True
print(isinstance("string", Drawable))  # False

# Operator polymorphism
print(1 + 2)        # 3 (int.__add__)
print("a" + "b")    # "ab" (str.__add__)
print([1] + [2])    # [1, 2] (list.__add__)

Quack!
I'm quacking like a duck!
name,age
Alice,30

Drawing circle
Drawing square
True
False
3
ab
[1, 2]

Key Points

•Duck typing: check behavior, not type -- no inheritance required
•Protocol provides formalized duck typing with type checker support
•Operator overloading is built-in polymorphism (+ works on ints, strings, lists)
•EAFP (try/except) is preferred over LBYL (isinstance) in Python

Gotchas

•Duck typing errors appear at runtime, not compile time
•@runtime_checkable Protocol only checks method existence, not signatures
•isinstance checks are often a code smell -- prefer duck typing
•Protocol checks are structural (has the method), not behavioral (does it work correctly)

Polymorphism in Python works through duck typing (check behavior, not type), method overriding, and operator overloading. No inheritance needed -- if it has the right methods, it works.

•Duck typing: behavior over type
•Protocol formalizes duck typing for type checkers

from typing import Protocol

class Speakable(Protocol):
    def speak(self) -> str: ...

class Dog:
    def speak(self) -> str: return "Woof"

class Robot:
    def speak(self) -> str: return "Beep"

def greet(s: Speakable) -> str:
    return s.speak()  # works with any object that has speak()

print(greet(Dog()))    # Woof
print(greet(Robot()))  # Beep

Woof
Beep

Duck typing errors are runtime only

Question 8 / 15

How do `isinstance` and `issubclass` work, and when should you use them?

isinstance(obj, classinfo) checks if an object is an instance of a class or a tuple of classes. It respects inheritance -- an instance of a subclass is also an instance of the parent.

issubclass(cls, classinfo) checks if a class is a subclass of another class. A class is considered a subclass of itself.

Both accept tuples for checking against multiple types: isinstance(x, (int, float)).

When to use:

Use isinstance for type guards, especially when different types need fundamentally different handling (e.g., in __eq__ methods, serialization)
Avoid isinstance when duck typing suffices -- checking for methods is more Pythonic
Use issubclass in metaclasses, class decorators, or framework code that inspects class hierarchies

Pseudo Code

isinstance(obj, Class) -> True if obj is instance of Class or subclass
isinstance(obj, (A, B)) -> True if instance of A OR B
issubclass(Child, Parent) -> True if Child inherits from Parent
issubclass(X, X) -> True (a class is its own subclass)

Prefer duck typing over isinstance in most cases

Code

class Animal:
    pass

class Dog(Animal):
    pass

class Cat(Animal):
    pass

dog = Dog()

# isinstance checks inheritance chain
print(isinstance(dog, Dog))     # True
print(isinstance(dog, Animal))  # True (Dog is subclass of Animal)
print(isinstance(dog, Cat))     # False
print(isinstance(dog, object))  # True (everything inherits from object)

# Tuple for multiple types
print(isinstance(dog, (Dog, Cat)))  # True (is Dog OR Cat)
print(isinstance(42, (int, float)))  # True

# issubclass works on classes, not instances
print(issubclass(Dog, Animal))    # True
print(issubclass(Dog, Dog))       # True (class is subclass of itself)
print(issubclass(Dog, Cat))       # False
print(issubclass(bool, int))      # True (bool is subclass of int!)

# When isinstance IS appropriate: __eq__ method
class Money:
    def __init__(self, amount, currency):
        self.amount = amount
        self.currency = currency

    def __eq__(self, other):
        if not isinstance(other, Money):  # type guard is appropriate here
            return NotImplemented
        return self.amount == other.amount and self.currency == other.currency

# When isinstance is a code smell: prefer duck typing
def process_bad(data):
    if isinstance(data, list):
        return sum(data)
    elif isinstance(data, dict):
        return sum(data.values())

def process_good(data):
    # Works with any iterable -- more Pythonic
    return sum(data) if not isinstance(data, dict) else sum(data.values())

# Even better: just use the protocol
def total(items):
    """Works with any iterable of numbers."""
    return sum(items)

print(total([1, 2, 3]))   # 6
print(total((4, 5, 6)))   # 15
print(total({7, 8, 9}))   # 24

# ABCs and isinstance
from collections.abc import Mapping, Iterable

print(isinstance({}, Mapping))     # True
print(isinstance([], Iterable))    # True
print(isinstance("hi", Iterable))  # True

True
True
False
True
True
True
True
True
False
True
6
15
24
True
True
True

Key Points

•isinstance checks object's type including inheritance chain
•issubclass checks class hierarchy
•Both accept tuples: isinstance(x, (int, float))
•Prefer duck typing over isinstance when possible

Gotchas

•isinstance(True, int) is True -- bool is a subclass of int
•type(x) == int fails for subclasses; isinstance(x, int) is preferred
•Excessive isinstance checks indicate you should use polymorphism instead
•issubclass raises TypeError if first arg is not a class

isinstance(obj, Class) checks if obj is an instance of Class or its subclasses. issubclass(A, B) checks class hierarchy. Both accept tuples. Prefer duck typing over isinstance.

•isinstance respects inheritance
•Use tuples for OR checks

class Animal: pass
class Dog(Animal): pass

dog = Dog()
print(isinstance(dog, Dog))     # True
print(isinstance(dog, Animal))  # True (inheritance)
print(isinstance(42, (int, float)))  # True (tuple = OR)
print(issubclass(Dog, Animal))  # True

True
True
True
True

isinstance(True, int) is True because bool subclasses int

Question 9 / 15

When should you use composition over inheritance?

Inheritance (is-a relationship): A Dog IS an Animal. The child inherits the parent's interface and implementation. Changes to the parent affect all children.

Composition (has-a relationship): A Car HAS an Engine. Objects contain other objects as attributes. Each component can be changed independently.

Prefer composition when:

You want to reuse code without inheriting an interface
The relationship is "has-a" not "is-a"
You need to combine behaviors from multiple sources
You want loose coupling and easy testing (inject mock components)
The parent class might change in ways that break children

Prefer inheritance when:

There's a genuine "is-a" relationship
You need polymorphism (substitutability)
You're implementing an interface/ABC
The relationship is stable and unlikely to change

Pseudo Code

Inheritance (is-a):
  class Dog(Animal) -- Dog IS an Animal
  Tight coupling, shared interface

Composition (has-a):
  class Car:
      self.engine = Engine() -- Car HAS an Engine
  Loose coupling, independent components

Favor composition for:
  - Code reuse without interface inheritance
  - Flexible, swappable components
  - Easy testing with dependency injection

Code

# BAD: Inheritance for code reuse (not is-a)
class DatabaseConnection:
    def connect(self):
        return "connected"

    def execute(self, query):
        return f"executing: {query}"

class UserRepository(DatabaseConnection):  # is UserRepo a DB connection? NO!
    def get_user(self, user_id):
        return self.execute(f"SELECT * FROM users WHERE id={user_id}")

# GOOD: Composition -- UserRepository HAS a connection
class UserRepository:
    def __init__(self, db):
        self.db = db  # injected dependency

    def get_user(self, user_id):
        return self.db.execute(f"SELECT * FROM users WHERE id={user_id}")

# Easy to test with mock
class MockDB:
    def execute(self, query):
        return {"id": 1, "name": "Alice"}

repo = UserRepository(MockDB())  # inject mock for testing
print(repo.get_user(1))  # {'id': 1, 'name': 'Alice'}

# GOOD: Composition for flexible behavior
class Engine:
    def __init__(self, horsepower):
        self.hp = horsepower

    def start(self):
        return f"Engine ({self.hp}hp) started"

class Transmission:
    def __init__(self, type_="automatic"):
        self.type = type_

    def shift(self, gear):
        return f"{self.type}: shifting to {gear}"

class Car:
    def __init__(self, engine: Engine, transmission: Transmission):
        self.engine = engine
        self.transmission = transmission

    def drive(self):
        return f"{self.engine.start()} | {self.transmission.shift('D')}"

# Components are swappable
sedan = Car(Engine(200), Transmission("automatic"))
sports = Car(Engine(450), Transmission("manual"))

print(sedan.drive())   # Engine (200hp) started | automatic: shifting to D
print(sports.drive())  # Engine (450hp) started | manual: shifting to D

# GOOD: Inheritance for genuine is-a with polymorphism
from abc import ABC, abstractmethod

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

class Circle(Shape):  # Circle IS a Shape -- correct use of inheritance
    def __init__(self, radius):
        self.radius = radius

    def area(self) -> float:
        import math
        return math.pi * self.radius ** 2

def total_area(shapes: list) -> float:
    return sum(s.area() for s in shapes)  # polymorphism

{'id': 1, 'name': 'Alice'}
Engine (200hp) started | automatic: shifting to D
Engine (450hp) started | manual: shifting to D

Key Points

•Composition for has-a, inheritance for is-a
•Composition enables dependency injection and easy testing
•Components can be swapped independently
•Inheritance is correct for genuine type hierarchies and polymorphism

Gotchas

•Inheriting for code reuse without an is-a relationship creates fragile base class problem
•Changes to parent class can unexpectedly break all children
•Deep inheritance hierarchies are hard to understand and maintain
•Composition requires more boilerplate (delegation) but is more flexible

Use composition (has-a) for code reuse, loose coupling, and testability. Use inheritance (is-a) for genuine type hierarchies and polymorphism. Composition is more flexible; inheritance is more concise.

•Composition for has-a, inheritance for is-a
•Composition enables dependency injection

# Composition: Car HAS an Engine
class Engine:
    def start(self): return "Vroom"

class Car:
    def __init__(self, engine):
        self.engine = engine  # composition
    def drive(self):
        return self.engine.start()

car = Car(Engine())
print(car.drive())  # Vroom

# Easy to test: inject mock
class MockEngine:
    def start(self): return "Mock Vroom"

test_car = Car(MockEngine())

Vroom

Inheriting for code reuse without is-a creates fragile hierarchies

Question 10 / 15

What is the Liskov Substitution Principle (LSP) and how does it apply to Python?

The Liskov Substitution Principle (LSP) states: "Objects of a superclass should be replaceable with objects of a subclass without altering the correctness of the program."

In practice, this means:

A subclass must accept all inputs the parent accepts (same or wider preconditions)
A subclass must return the same type or a subtype (covariant returns)
A subclass must not throw new exceptions the parent doesn't throw
A subclass must preserve the parent's invariants
A subclass should not change the expected behavior of inherited methods

Violating LSP leads to brittle code where isinstance checks proliferate and polymorphism breaks. The classic example is Square inheriting from Rectangle -- setting width on a Square should also set height, violating Rectangle's expected behavior.

Pseudo Code

LSP Rules:
1. Subclass can accept same or more inputs
2. Subclass returns same or narrower output type
3. Subclass preserves parent invariants
4. Code using parent should work with any subclass

Violation test: If replacing parent with child breaks code, LSP is violated

Code

# LSP VIOLATION: Square extends Rectangle
class Rectangle:
    def __init__(self, width, height):
        self._width = width
        self._height = height

    @property
    def width(self):
        return self._width

    @width.setter
    def width(self, value):
        self._width = value

    @property
    def height(self):
        return self._height

    @height.setter
    def height(self, value):
        self._height = value

    def area(self):
        return self._width * self._height

class Square(Rectangle):  # LSP VIOLATION!
    def __init__(self, side):
        super().__init__(side, side)

    @Rectangle.width.setter
    def width(self, value):
        self._width = value
        self._height = value  # forces equal sides

    @Rectangle.height.setter
    def height(self, value):
        self._width = value
        self._height = value

# This function works with Rectangle but breaks with Square
def test_rectangle(rect):
    rect.width = 5
    rect.height = 10
    assert rect.area() == 50, f"Expected 50, got {rect.area()}"

test_rectangle(Rectangle(1, 1))  # passes
try:
    test_rectangle(Square(1))  # FAILS! area is 100, not 50
except AssertionError as e:
    print(e)  # Expected 50, got 100

# LSP-COMPLIANT: Use composition or separate hierarchy
from abc import ABC, abstractmethod

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

class Rectangle(Shape):
    def __init__(self, width, height):
        self.width = width
        self.height = height

    def area(self) -> float:
        return self.width * self.height

class Square(Shape):  # NOT a subclass of Rectangle
    def __init__(self, side):
        self.side = side

    def area(self) -> float:
        return self.side ** 2

# Both satisfy Shape contract independently
def print_area(shape: Shape):
    print(f"{shape.__class__.__name__}: {shape.area()}")

print_area(Rectangle(5, 10))  # Rectangle: 50
print_area(Square(5))         # Square: 25

# Another LSP-compliant example
class Bird(ABC):
    @abstractmethod
    def move(self) -> str: ...  # NOT fly() -- penguins can't fly

class Sparrow(Bird):
    def move(self) -> str:
        return "flying"

class Penguin(Bird):
    def move(self) -> str:
        return "swimming"  # still moves, just differently

Expected 50, got 100
Rectangle: 50
Square: 25

Key Points

•Subclass instances must be usable wherever parent instances are expected
•Don't override methods in ways that break parent's contract
•Classic violation: Square extends Rectangle (side coupling breaks width/height independence)
•Fix: use a common ABC or composition instead of forcing an is-a relationship

Gotchas

•Python doesn't enforce LSP -- it's a design principle you must follow voluntarily
•Raising exceptions a parent doesn't raise violates LSP
•Strengthening preconditions (accepting fewer inputs) violates LSP
•Weakening postconditions (returning unexpected types) violates LSP

LSP: subclass objects must work wherever parent objects are used. If replacing a parent with a child breaks code, LSP is violated. Classic example: Square should not extend Rectangle.

•Subclass must be substitutable for parent
•Don't force is-a when behavior differs

from abc import ABC, abstractmethod

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

class Rectangle(Shape):
    def __init__(self, w, h):
        self.w, self.h = w, h
    def area(self): return self.w * self.h

class Square(Shape):  # separate, not subclass of Rectangle
    def __init__(self, side):
        self.side = side
    def area(self): return self.side ** 2

# Both satisfy Shape contract independently

Square(Rectangle) violates LSP -- use separate hierarchy

Question 11 / 15

What is the `Protocol` class in Python, and how does it enable structural subtyping?

typing.Protocol (Python 3.8+) formalizes duck typing by defining structural subtyping. A class satisfies a Protocol if it has the required methods/attributes, even without explicit inheritance.

This contrasts with nominal subtyping (ABCs) where you must explicitly inherit from the base class.

Protocol advantages:

Works with third-party classes you can't modify
No inheritance required (structural/duck typing)
Type checkers (mypy) validate at static analysis time
@runtime_checkable enables isinstance checks (method existence only)

Protocol is the Pythonic way to define interfaces -- it aligns with duck typing while adding type safety.

Pseudo Code

1. class MyProtocol(Protocol):
2.     def method(self) -> Type: ...
3. Any class with matching method satisfies MyProtocol
4. No inheritance needed
5. @runtime_checkable adds isinstance support

Code

from typing import Protocol, runtime_checkable, Iterable

# Define a protocol
class Closable(Protocol):
    def close(self) -> None: ...

# These satisfy Closable WITHOUT inheriting from it
class FileWrapper:
    def __init__(self, path):
        self.path = path

    def close(self) -> None:
        print(f"Closing {self.path}")

class DatabaseConn:
    def close(self) -> None:
        print("Closing DB connection")

def cleanup(resource: Closable) -> None:
    """Works with anything that has close()."""
    resource.close()

cleanup(FileWrapper("/tmp/data"))  # Closing /tmp/data
cleanup(DatabaseConn())            # Closing DB connection

# runtime_checkable for isinstance checks
@runtime_checkable
class Drawable(Protocol):
    def draw(self) -> str: ...

class Circle:
    def draw(self) -> str:
        return "O"

class Point:
    pass

print(isinstance(Circle(), Drawable))  # True
print(isinstance(Point(), Drawable))   # False

# Protocol with attributes and properties
class Named(Protocol):
    name: str  # attribute protocol

class User:
    def __init__(self, name: str):
        self.name = name

def greet(entity: Named) -> str:
    return f"Hello, {entity.name}!"

print(greet(User("Alice")))  # Hello, Alice!

# Protocol with multiple methods
class Repository(Protocol):
    def get(self, id: int) -> dict: ...
    def save(self, item: dict) -> None: ...
    def delete(self, id: int) -> None: ...

class InMemoryRepo:
    def __init__(self):
        self.data = {}

    def get(self, id: int) -> dict:
        return self.data.get(id, {})

    def save(self, item: dict) -> None:
        self.data[item["id"]] = item

    def delete(self, id: int) -> None:
        self.data.pop(id, None)

def process_items(repo: Repository) -> None:
    repo.save({"id": 1, "name": "Item 1"})
    print(repo.get(1))

process_items(InMemoryRepo())  # {'id': 1, 'name': 'Item 1'}

Closing /tmp/data
Closing DB connection
True
False
Hello, Alice!
{'id': 1, 'name': 'Item 1'}

Key Points

•Protocol defines interfaces via structural subtyping (no inheritance needed)
•Any class with matching methods satisfies the Protocol
•@runtime_checkable enables isinstance checks
•Works with third-party classes you can't modify

Gotchas

•@runtime_checkable only checks method existence, not signatures or return types
•Protocol is checked statically by mypy but not enforced at runtime (without @runtime_checkable)
•Cannot use Protocol in except clauses or with issubclass for non-Protocol classes
•Attribute protocols with @runtime_checkable may not work correctly (checks class, not instance)

Protocol defines interfaces through structural subtyping -- no inheritance needed. Any class with matching methods satisfies the Protocol. Use @runtime_checkable for isinstance support.

•Structural subtyping -- no inheritance required
•@runtime_checkable for isinstance support

from typing import Protocol, runtime_checkable

@runtime_checkable
class Sortable(Protocol):
    def __lt__(self, other) -> bool: ...

class Score:
    def __init__(self, value):
        self.value = value
    def __lt__(self, other):
        return self.value < other.value

print(isinstance(Score(10), Sortable))  # True
print(isinstance("hello", Sortable))    # True (str has __lt__)

True
True

@runtime_checkable only checks method existence, not signatures

Question 12 / 15

How does the `super()` function work with multiple inheritance?

In multiple inheritance, super() doesn't simply call the "parent" -- it calls the next class in the MRO of the actual instance's class. This enables cooperative multiple inheritance where each class in the chain calls super() to pass control to the next class.

The key insight: super() in class B might call class C (not A), depending on the MRO of the class that initiated the chain. This means the behavior of super() depends on the final class in the hierarchy, not just the local class.

For cooperative multiple inheritance to work:

All classes in the chain must call super()
The base class (usually object) terminates the chain
**kwargs should be used to pass through unexpected keyword arguments
Each class takes only the parameters it needs and passes the rest along

Pseudo Code

class D(B, C):
  MRO: D -> B -> C -> A -> object

super() in D -> calls B
super() in B -> calls C (next in MRO of D, NOT A!)
super() in C -> calls A
super() in A -> calls object

For cooperative __init__:
  Each class takes its params and passes **kwargs to super()

Code

# super() follows MRO, not direct parent
class A:
    def __init__(self, **kwargs):
        print(f"A.__init__({kwargs})")
        super().__init__(**kwargs)

class B(A):
    def __init__(self, b_param=None, **kwargs):
        print(f"B.__init__(b_param={b_param})")
        super().__init__(**kwargs)

class C(A):
    def __init__(self, c_param=None, **kwargs):
        print(f"C.__init__(c_param={c_param})")
        super().__init__(**kwargs)

class D(B, C):
    def __init__(self, d_param=None, **kwargs):
        print(f"D.__init__(d_param={d_param})")
        super().__init__(**kwargs)

print(D.__mro__)  # D -> B -> C -> A -> object

D(d_param="d", b_param="b", c_param="c")
# D.__init__(d_param=d)
# B.__init__(b_param=b)     <- super() in D calls B
# C.__init__(c_param=c)     <- super() in B calls C (not A!)
# A.__init__({})             <- super() in C calls A

# Demonstrating that super() depends on the instance's class
class X:
    def method(self):
        print("X.method")

class Y(X):
    def method(self):
        print("Y.method")
        super().method()  # calls next in MRO

class Z(X):
    def method(self):
        print("Z.method")
        super().method()

class W(Y, Z):  # MRO: W -> Y -> Z -> X -> object
    pass

W().method()
# Y.method
# Z.method  <- super() in Y calls Z, not X!
# X.method

# Without W, Y's super() goes directly to X:
Y().method()
# Y.method
# X.method  <- now super() in Y calls X

# super() with explicit arguments
class Parent:
    def greet(self):
        return "Hello from Parent"

class Child(Parent):
    def greet(self):
        # super(Child, self).greet() is equivalent to super().greet()
        return super(Child, self).greet() + " and Child"

(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <class 'object'>)
D.__init__(d_param=d)
B.__init__(b_param=b)
C.__init__(c_param=c)
A.__init__({})
Y.method
Z.method
X.method
Y.method
X.method

Key Points

•super() calls the next class in MRO, not necessarily the direct parent
•The MRO depends on the actual instance's class, not the local class
•Use **kwargs to pass parameters through the cooperative chain
•All classes must call super() for the chain to work

Gotchas

•super() in B may call C instead of A depending on the final class's MRO
•If one class in the chain doesn't call super(), the chain breaks
•Incompatible __init__ signatures make cooperative inheritance difficult
•Always use keyword arguments in cooperative __init__ to handle parameter routing

super() calls the next class in the MRO, not the direct parent. In class D(B, C), super() in B calls C. Use **kwargs to route parameters through the chain.

•super() follows MRO, not direct parent
•Behavior depends on the final class in the hierarchy

class A:
    def who(self): print("A")
class B(A):
    def who(self): print("B"); super().who()
class C(A):
    def who(self): print("C"); super().who()
class D(B, C):  # MRO: D->B->C->A
    def who(self): print("D"); super().who()

D().who()  # D, B, C, A (super in B calls C, not A!)

D
B
C
A

super() in B may call C instead of A depending on context

Question 13 / 15

What is the Interface Segregation Principle and how does Python approach interfaces?

The Interface Segregation Principle (ISP) states: "No client should be forced to depend on methods it doesn't use." Instead of one large interface, split it into smaller, specific ones.

Python approaches interfaces through:

ABCs (abc module): Nominal subtyping -- must explicitly inherit
Protocol (typing): Structural subtyping -- no inheritance needed
Duck typing: Implicit -- just use the methods you need

ISP is naturally supported by Python's duck typing and Protocol. You don't need to implement unused methods because Python doesn't require explicit interface declarations. Functions only call the methods they need, and any object with those methods works.

However, when designing ABCs, ISP is important: keep abstract base classes small and focused. Split large interfaces into multiple mixins or protocols.

Pseudo Code

BAD: One fat interface
  class Worker(ABC):
      work(), eat(), sleep(), code(), manage()
  # Managers don't code, developers don't manage

GOOD: Segregated interfaces
  class Workable(Protocol): work()
  class Feedable(Protocol): eat()
  class Codeable(Protocol): code()
  class Manageable(Protocol): manage()

Code

from typing import Protocol
from abc import ABC, abstractmethod

# BAD: Fat interface forces unused implementations
class BadWorker(ABC):
    @abstractmethod
    def work(self): ...
    @abstractmethod
    def eat(self): ...
    @abstractmethod
    def code(self): ...
    @abstractmethod
    def manage(self): ...

# Managers forced to implement code(), developers forced to implement manage()

# GOOD: Segregated protocols
class Workable(Protocol):
    def work(self) -> str: ...

class Feedable(Protocol):
    def eat(self) -> str: ...

class Codeable(Protocol):
    def code(self) -> str: ...

class Manageable(Protocol):
    def manage(self) -> str: ...

# Each class implements only what it needs
class Developer:
    def work(self) -> str:
        return "Developing features"

    def eat(self) -> str:
        return "Eating lunch"

    def code(self) -> str:
        return "Writing Python"

class Manager:
    def work(self) -> str:
        return "Leading team"

    def eat(self) -> str:
        return "Business lunch"

    def manage(self) -> str:
        return "Managing projects"

# Functions depend only on what they need
def assign_task(worker: Workable) -> str:
    return worker.work()

def lunch_break(entity: Feedable) -> str:
    return entity.eat()

def code_review(coder: Codeable) -> str:
    return coder.code()

# Both work where needed
dev = Developer()
mgr = Manager()

print(assign_task(dev))    # Developing features
print(assign_task(mgr))    # Leading team
print(code_review(dev))    # Writing Python
# code_review(mgr)  # mypy error: Manager doesn't satisfy Codeable

# Real-world example: file-like objects
class Readable(Protocol):
    def read(self, n: int = -1) -> str: ...

class Writable(Protocol):
    def write(self, data: str) -> int: ...

class ReadWritable(Readable, Writable, Protocol):
    pass  # compose protocols when needed

def process_input(source: Readable) -> str:
    return source.read()

def write_output(dest: Writable, data: str) -> None:
    dest.write(data)

Developing features
Leading team
Writing Python

Key Points

•ISP: don't force classes to implement methods they don't use
•Split large interfaces into small, focused Protocols
•Python's duck typing naturally supports ISP
•Functions should depend on the minimal interface they need

Gotchas

•Over-segregation creates too many tiny protocols -- find the right granularity
•ABCs enforce implementation at instantiation time; Protocols at type-check time (or not at all)
•Combining many protocols via multiple inheritance works but adds complexity
•Duck typing means ISP violations are less painful in Python than in Java

ISP: split large interfaces into small, focused ones. In Python, use multiple small Protocols instead of one large ABC. Functions should depend only on the methods they actually call.

•Small, focused protocols over large ABCs
•Depend only on methods you actually use

from typing import Protocol

class Readable(Protocol):
    def read(self) -> str: ...

class Writable(Protocol):
    def write(self, data: str) -> None: ...

def process(source: Readable):
    return source.read()  # only needs read()

def save(dest: Writable, data: str):
    dest.write(data)  # only needs write()

Over-segregation creates too many tiny interfaces

Question 14 / 15

How do abstract properties and abstract class methods work?

Abstract base classes can have abstract properties and abstract class/static methods. Subclasses must implement these or they cannot be instantiated.

For abstract properties, stack @property with @abstractmethod (with @abstractmethod as the innermost decorator). For abstract class methods, stack @classmethod with @abstractmethod.

In Python 3.3+, @abstractproperty, @abstractclassmethod, and @abstractstaticmethod are deprecated in favor of stacking decorators.

Pseudo Code

Abstract property:
  @property
  @abstractmethod
  def prop(self): ...

Abstract classmethod:
  @classmethod
  @abstractmethod
  def method(cls): ...

Abstract staticmethod:
  @staticmethod
  @abstractmethod
  def method(): ...

Rule: @abstractmethod must be innermost decorator

Code

from abc import ABC, abstractmethod

class Vehicle(ABC):
    @property
    @abstractmethod
    def fuel_type(self) -> str:
        """Must return the vehicle's fuel type."""
        ...

    @property
    @abstractmethod
    def max_speed(self) -> int:
        """Must return max speed in km/h."""
        ...

    @classmethod
    @abstractmethod
    def from_config(cls, config: dict) -> 'Vehicle':
        """Factory method that subclasses must implement."""
        ...

    @staticmethod
    @abstractmethod
    def vehicle_type() -> str:
        """Return the type of vehicle."""
        ...

    def describe(self) -> str:
        return f"{self.vehicle_type()}: {self.fuel_type}, max {self.max_speed} km/h"

# Must implement ALL abstract properties and methods
class ElectricCar(Vehicle):
    def __init__(self, model: str, speed: int):
        self.model = model
        self._max_speed = speed

    @property
    def fuel_type(self) -> str:
        return "electric"

    @property
    def max_speed(self) -> int:
        return self._max_speed

    @classmethod
    def from_config(cls, config: dict) -> 'ElectricCar':
        return cls(config["model"], config["speed"])

    @staticmethod
    def vehicle_type() -> str:
        return "Car"

car = ElectricCar("Tesla", 250)
print(car.describe())  # Car: electric, max 250 km/h

car2 = ElectricCar.from_config({"model": "Rivian", "speed": 200})
print(car2.describe())  # Car: electric, max 200 km/h

# Incomplete implementation fails
try:
    class IncompleteCar(Vehicle):
        @property
        def fuel_type(self) -> str:
            return "gas"
        # Missing: max_speed, from_config, vehicle_type

    IncompleteCar()  # TypeError!
except TypeError as e:
    print(e)

# Abstract property with setter
class Configurable(ABC):
    @property
    @abstractmethod
    def setting(self) -> str: ...

    @setting.setter
    @abstractmethod
    def setting(self, value: str) -> None: ...

class AppConfig(Configurable):
    def __init__(self):
        self._setting = "default"

    @property
    def setting(self) -> str:
        return self._setting

    @setting.setter
    def setting(self, value: str) -> None:
        self._setting = value

c = AppConfig()
c.setting = "custom"
print(c.setting)  # custom

Car: electric, max 250 km/h
Car: electric, max 200 km/h
Can't instantiate abstract class IncompleteCar without an implementation for abstract methods 'from_config', 'max_speed', 'vehicle_type'
custom

Key Points

•Stack @property/@classmethod/@staticmethod with @abstractmethod
•@abstractmethod must be the innermost (closest to function) decorator
•Subclasses must implement all abstract properties, classmethods, and staticmethods
•Incomplete implementation raises TypeError at instantiation

Gotchas

•@abstractmethod must be innermost -- wrong order causes it to be ignored
•The deprecated @abstractproperty still works but should not be used
•Abstract properties with setters require both getter and setter to be abstract
•Abstract classmethod must use cls() not ClassName() to support subclass chaining

Stack @property or @classmethod with @abstractmethod (innermost). Subclasses must implement all abstract members. Incomplete implementation raises TypeError.

•@abstractmethod must be innermost decorator
•Subclasses must implement all abstract members

from abc import ABC, abstractmethod

class Animal(ABC):
    @property
    @abstractmethod
    def sound(self) -> str: ...

    @classmethod
    @abstractmethod
    def create(cls, name: str) -> 'Animal': ...

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

    @property
    def sound(self): return "Woof"

    @classmethod
    def create(cls, name): return cls(name)

Wrong decorator order silently fails to enforce abstraction

Question 15 / 15

How do you use `subclasshook` for custom isinstance/issubclass behavior?

__subclasshook__ is a class method on ABCs that customizes isinstance and issubclass checks. It allows you to define when a class should be considered a subclass without explicit inheritance or registration.

When isinstance(obj, MyABC) or issubclass(cls, MyABC) is called, Python checks MyABC.__subclasshook__(cls). If it returns:

True: the class IS considered a subclass
False: the class is NOT a subclass
NotImplemented: fall back to normal checking

This is how collections.abc works -- for example, any class with __iter__ and __next__ is considered an Iterator without explicit inheritance.

Pseudo Code

1. Define __subclasshook__(cls, C) as @classmethod on ABC
2. Check if C has the required methods/attributes
3. Return True if it qualifies, NotImplemented otherwise
4. isinstance/issubclass will use this hook
5. Used by collections.abc internally

Code

from abc import ABC, abstractmethod

class Closable(ABC):
    @abstractmethod
    def close(self) -> None:
        ...

    @classmethod
    def __subclasshook__(cls, C):
        if cls is Closable:
            # Check if C has a 'close' method
            if any("close" in B.__dict__ for B in C.__mro__):
                return True
        return NotImplemented

# No inheritance from Closable!
class FileWrapper:
    def close(self):
        pass

class Connection:
    def close(self):
        pass

class NoClose:
    pass

# isinstance works through __subclasshook__
print(isinstance(FileWrapper(), Closable))  # True
print(isinstance(Connection(), Closable))   # True
print(isinstance(NoClose(), Closable))      # False

print(issubclass(FileWrapper, Closable))    # True
print(issubclass(NoClose, Closable))        # False

# How collections.abc uses this internally
from collections.abc import Iterable, Iterator, Sized

class MyRange:
    def __init__(self, n):
        self.n = n

    def __iter__(self):
        return iter(range(self.n))

    def __len__(self):
        return self.n

# MyRange satisfies Iterable and Sized through __subclasshook__
print(isinstance(MyRange(10), Iterable))  # True (has __iter__)
print(isinstance(MyRange(10), Sized))     # True (has __len__)
print(isinstance(MyRange(10), Iterator))  # False (no __next__)

# Practical: defining a duck-typed interface
class Serializable(ABC):
    @classmethod
    def __subclasshook__(cls, C):
        if cls is Serializable:
            if (any("to_dict" in B.__dict__ for B in C.__mro__) and
                any("from_dict" in B.__dict__ for B in C.__mro__)):
                return True
        return NotImplemented

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

    def to_dict(self):
        return {"name": self.name}

    @classmethod
    def from_dict(cls, data):
        return cls(data["name"])

print(isinstance(User("Alice"), Serializable))  # True

True
True
False
True
False
True
True
False
True

Key Points

•__subclasshook__ customizes isinstance/issubclass for ABCs
•Return True (is subclass), False (not), or NotImplemented (use normal check)
•Enables structural typing with isinstance checks
•collections.abc uses this for Iterable, Sized, etc.

Gotchas

•Must check cls is YourABC to avoid false positives in subclasses of the ABC
•Only checks method existence, not signature or behavior
•Returning NotImplemented (not False) lets normal isinstance logic proceed
•__subclasshook__ is checked before __instancecheck__ and .register()

__subclasshook__ on an ABC customizes isinstance/issubclass to check for methods structurally. Return True, False, or NotImplemented. Used by collections.abc internally.

•Customizes isinstance for structural checking
•Return True/False/NotImplemented

from abc import ABC

class Printable(ABC):
    @classmethod
    def __subclasshook__(cls, C):
        if cls is Printable:
            if any("__str__" in B.__dict__ for B in C.__mro__):
                return True
        return NotImplemented

class Foo:
    def __str__(self): return "Foo"

print(isinstance(Foo(), Printable))  # True (has __str__)

True

Always check 'cls is MyABC' to prevent false positives in subclasses

Built by onllm.dev

Home GitHub Support awesomePrep

How does single inheritance work in Python, and how do you use `super()`?

How does multiple inheritance work in Python, and what is the diamond problem?

What is the MRO (Method Resolution Order) and how does C3 linearization work?

What are abstract base classes (ABCs) and how do you use the `abc` module?

What are mixins in Python, and how do they differ from regular inheritance?

How do you override methods in Python, and what is method overriding vs overloading?

What is polymorphism in Python, and how does duck typing relate to it?

How do `isinstance` and `issubclass` work, and when should you use them?

When should you use composition over inheritance?

What is the Liskov Substitution Principle (LSP) and how does it apply to Python?

What is the `Protocol` class in Python, and how does it enable structural subtyping?

How does the `super()` function work with multiple inheritance?

What is the Interface Segregation Principle and how does Python approach interfaces?

How do abstract properties and abstract class methods work?

How do you use `__subclasshook__` for custom isinstance/issubclass behavior?

OOP: Inheritance, Polymorphism, MRO

How do you use `subclasshook` for custom isinstance/issubclass behavior?