Object-Oriented Programming in Python

Classes are instances of type

class Foo:
    pass

type(Foo)          # <class 'type'>
type(Foo())        # <class '__main__.Foo'>

Foo is itself an object — an instance of type. A metaclass is just a class whose instances are classes, i.e., a subclass of type.

Writing a metaclass

class RegisteringMeta(type):
    registry = {}

    def __new__(mcs, name, bases, namespace):
        cls = super().__new__(mcs, name, bases, namespace)
        if name != "Base":
            mcs.registry[name] = cls
        return cls

class Base(metaclass=RegisteringMeta):
    pass

class PluginA(Base):
    pass

class PluginB(Base):
    pass

RegisteringMeta.registry   # {'PluginA': <class PluginA>, 'PluginB': <class PluginB>}

Every time a class is defined with metaclass=RegisteringMeta in its hierarchy, RegisteringMeta.__new__ runs during class creation (not instance creation) — this is how plugin auto-registration, ORMs (Django models, SQLAlchemy declarative base), and enum-like machinery work under the hood.

The lighter-weight alternative: __init_subclass__

class Base:
    registry = {}

    def __init_subclass__(cls, **kwargs):
        super().__init_subclass__(**kwargs)
        Base.registry[cls.__name__] = cls

class PluginA(Base):
    pass

__init_subclass__ (PEP 487, Python 3.6+) covers the most common metaclass use case — reacting to subclass creation — without the complexity of writing a full metaclass, and it composes more predictably with multiple inheritance since there's no metaclass-conflict problem to worry about.

When a real metaclass is still justified

• You need to intercept class creation itself, not just subclassing (e.g., validating/transforming the class namespace before the class object even exists).
• You're building a framework-level abstraction (an ORM base class, an ABC-like mechanism) where __init_subclass__ genuinely isn't expressive enough.

The famous caution

"Metaclasses are deeper magic than 99% of users should ever worry about... If you wonder whether you need them, you don't." — Tim Peters

Interview-ready summary: A metaclass customizes how classes themselves are constructed by subclassing type; it's the mechanism behind ORMs and plugin registries. For the common "do something when a subclass is defined" need, prefer __init_subclass__ — reach for a full metaclass only when you must control class creation, not just react to subclassing.

The default cost: a __dict__ per instance

class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y

p = Point(1, 2)
p.__dict__          # {'x': 1, 'y': 2}
p.z = 3              # works -- __dict__ is dynamic, any attribute can be added

Every instance carries its own dict for attribute storage, which is flexible but has real memory overhead (~100+ bytes per instance just for the dict, on top of the attributes themselves) — significant if you create millions of small objects.

__slots__: fixed, dict-free storage

class Point:
    __slots__ = ("x", "y")

    def __init__(self, x, y):
        self.x = x
        self.y = y

p = Point(1, 2)
p.z = 3              # AttributeError: 'Point' object has no attribute 'z'
p.__dict__            # AttributeError: no __dict__ at all

With __slots__, Python allocates fixed-size storage for exactly the named attributes (implemented as descriptors under the hood), eliminating the per-instance dict entirely. For a class with millions of instances (e.g., points in a large dataset, nodes in a graph), this can cut memory use by 40-50%+ and speed up attribute access slightly too.

The tradeoffs

• No dynamic attributes — assigning an attribute not in __slots__ raises AttributeError. This is often a feature (catches typos early) but breaks code that relies on ad-hoc attribute assignment.
• No default __dict__ or __weakref__ unless explicitly included in __slots__ — if you need weak references to instances, add "__weakref__" to the slots tuple.
• Multiple inheritance is tricky — at most one base class in the MRO can have non-empty __slots__ with actual layout conflicts; combining multiple non-empty-__slots__ bases raises TypeError: multiple bases have instance lay-out conflict.
• Every subclass needs its own __slots__ — if a subclass doesn't declare __slots__, it gets a __dict__ anyway, silently undoing the memory savings for that subclass's instances.

When to use it

Reach for __slots__ on classes you'll instantiate in large numbers (data records, tree/graph nodes, simple value objects) where memory footprint matters — not as a default for every class, since it removes flexibility for comparatively small classes where the memory savings don't matter.

Interview-ready summary: __slots__ trades away per-instance dict flexibility for fixed, lower-memory attribute storage — a meaningful win when instantiating a class millions of times, but something to opt into deliberately (and consistently across a whole inheritance chain), not a default.

The boilerplate dataclasses remove

# Without dataclasses
class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y

    def __repr__(self):
        return f"Point(x={self.x!r}, y={self.y!r})"

    def __eq__(self, other):
        if not isinstance(other, Point):
            return NotImplemented
        return (self.x, self.y) == (other.x, other.y)

# With dataclasses -- same behavior, generated automatically
from dataclasses import dataclass

@dataclass
class Point:
    x: int
    y: int

@dataclass reads the class's type annotations and generates __init__, __repr__, and __eq__ for you. Point(1, 2) == Point(1, 2) is True, and repr(Point(1, 2)) prints Point(x=1, y=2) — both for free.

Useful options

from dataclasses import dataclass, field

@dataclass(order=True, frozen=True)
class Money:
    cents: int
    currency: str = "USD"
    tags: list = field(default_factory=list)   # mutable default, done safely

m1 = Money(100)
m2 = Money(200)
m1 < m2            # True -- order=True generates __lt__ etc. (field-by-field)
m1.cents = 500      # FrozenInstanceError -- frozen=True makes it immutable

field(default_factory=...) solves the mutable-default-argument problem for dataclass fields specifically — you can't write tags: list = [] directly (dataclasses explicitly raise an error for mutable defaults without a factory).

Comparison to alternatives

namedtuple is best for genuinely tuple-like, immutable records accessed positionally as well as by name; @dataclass is the standard modern choice for "a class that's mostly data plus a few methods"; attrs remains popular when you need richer validation/conversion features than @dataclass's __post_init__ conveniently provides.

Interview-ready summary: @dataclass auto-generates __init__, __repr__, and __eq__ from annotated fields, removing the most common class boilerplate while staying a normal, mutable, inheritable class — reach for namedtuple for lightweight immutable tuples, and attrs when you need validators/converters beyond what @dataclass provides out of the box.

ABC: nominal typing, enforced at instantiation

from abc import ABC, abstractmethod

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

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

Shape()          # TypeError: Can't instantiate abstract class Shape
Circle(5).area()  # 78.5...

class Incomplete(Shape):
    pass

Incomplete()      # TypeError: Can't instantiate abstract class Incomplete
                   # with abstract method area

Shape explicitly declares a contract; Circle must explicitly inherit from Shape to be treated as one, and Python enforces at runtime that every abstract method is overridden before a concrete subclass can even be instantiated.

Protocol: structural typing, checked statically

from typing import Protocol, runtime_checkable

@runtime_checkable
class HasArea(Protocol):
    def area(self) -> float: ...

class Circle:                 # note: NOT inheriting from HasArea at all
    def __init__(self, r):
        self.r = r
    def area(self):
        return 3.14159 * self.r ** 2

def total_area(shapes: list[HasArea]) -> float:
    return sum(s.area() for s in shapes)

total_area([Circle(5)])            # type-checks fine — Circle matches structurally
isinstance(Circle(5), HasArea)     # True, because @runtime_checkable was used

Circle never mentions HasArea — mypy (or isinstance, with @runtime_checkable) verifies the match purely by comparing method signatures.

Key differences

When to use which

Use ABC when you own the class hierarchy and want a hard runtime guarantee that subclasses implement required methods (and possibly want to share concrete helper methods too). Use Protocol when you're describing an interface that unrelated or third-party classes already satisfy, and you only need static verification, not a runtime contract.

Interview-ready summary: ABC is nominal typing with runtime enforcement — you must inherit from it, and instantiation fails if abstract methods are missing. Protocol is structural typing checked statically — any class with matching methods satisfies it, no inheritance required, which is ideal for describing capabilities of classes you don't control.

Returning NotImplemented, not raising

class Vector:
    def __init__(self, x, y):
        self.x, self.y = x, y

    def __add__(self, other):
        if not isinstance(other, Vector):
            return NotImplemented    # let Python try other.__radd__(self)
        return Vector(self.x + other.x, self.y + other.y)

    def __repr__(self):
        return f"Vector({self.x}, {self.y})"

Vector(1, 2) + Vector(3, 4)   # Vector(4, 6)
Vector(1, 2) + 5               # TypeError: unsupported operand type(s)

Returning NotImplemented (a sentinel, not an exception) tells Python "I don't know how to handle this operand" — Python then tries the right-hand operand's __radd__, and only raises TypeError if that also fails. Raising an exception directly from __add__ would skip that fallback and could produce a worse error, or wrongly prevent a valid reflected operation.

The __eq__/__hash__ contract

Python's rule: if two objects are equal (a == b), they must have the same hash, because dicts/sets rely on this to find matching keys.

class Point:
    def __init__(self, x, y):
        self.x, self.y = x, y
    def __eq__(self, other):
        return isinstance(other, Point) and (self.x, self.y) == (other.x, other.y)

hash(Point(1, 2))   # TypeError: unhashable type: 'Point'

The moment you define __eq__, Python sets __hash__ = None on the class automatically, because the inherited identity-based __hash__ from object would now violate the contract (two equal-by-value Points would have different hashes, breaking dict/set lookups).

The fix

class Point:
    def __init__(self, x, y):
        self.x, self.y = x, y

    def __eq__(self, other):
        return isinstance(other, Point) and (self.x, self.y) == (other.x, other.y)

    def __hash__(self):
        return hash((self.x, self.y))   # consistent with __eq__

Hash based on exactly the same fields used in __eq__ — this guarantees equal objects hash equally. If a class is meant to be mutable and therefore intentionally unhashable (a common convention: mutable objects shouldn't be dict keys, since mutating them after insertion would corrupt the hash table), it's fine to leave __hash__ as None deliberately — just make that choice consciously rather than by accident.

Rich comparison methods

For ordering, implement __lt__, __le__, __gt__, __ge__ individually, or use functools.total_ordering to derive the rest from just __eq__ and one of them.

Interview-ready summary: Dunder operator methods should return NotImplemented (never raise) for unsupported operand types, so Python can fall back to the reflected method. Defining __eq__ silently disables the default __hash__; if instances need to be hashable, define __hash__ explicitly using the same fields as __eq__.

Inheritance: is-a

class Vehicle:
    def start_engine(self):
        return "engine started"

class Car(Vehicle):   # a Car IS-A Vehicle
    def honk(self):
        return "beep!"

Car automatically gets everything Vehicle provides. This works well when the relationship is genuinely "is-a" and stable — a Car really is a kind of Vehicle, and that's unlikely to change.

Composition: has-a

class Engine:
    def start(self):
        return "engine started"

class Car:            # a Car HAS-A Engine (delegates to it)
    def __init__(self):
        self.engine = Engine()

    def start_engine(self):
        return self.engine.start()

Car doesn't inherit Engine's behavior — it holds an Engine instance and delegates to it. This decouples Car from Engine's implementation: swapping in an ElectricEngine just means constructing a different object, with no class-hierarchy changes.

Why composition is usually favored

• Looser coupling: a subclass inherits everything from its parent, including internals you may not want or that may change unexpectedly; composition only exposes what you explicitly delegate to.
• Flexibility at runtime: you can swap a composed object (car.engine = ElectricEngine()) without touching the class definition; swapping inherited behavior requires changing the class hierarchy.
• Avoids fragile base class problems: changes to a deeply inherited base class can silently break subclasses several levels down; composed objects have an explicit, narrower contract.
• Sidesteps multiple-inheritance/MRO complexity: composing several collaborator objects avoids diamond-inheritance and MRO conflicts entirely.

When inheritance is still the right call

• The relationship is genuinely "is-a" and unlikely to need swapping (e.g., class JSONDecodeError(ValueError) — a JSON decode error really is a kind of value error, permanently).
• You want to reuse a stable, well-tested base class's behavior via polymorphism (framework base classes like Django's Model, or ABCs meant specifically to be subclassed).
• Mixins for adding small, orthogonal, well-isolated behavior (LoggingMixin, TimestampMixin) — this is inheritance used in a composition-like, capability-additive way.

Interview-ready summary: Inheritance reuses behavior through an is-a relationship and a class hierarchy; composition reuses behavior through a has-a relationship and object delegation. Composition is usually the safer default because it's more loosely coupled and flexible — reserve inheritance for genuinely stable is-a relationships or narrow, well-scoped mixins.

Approach 1: a module (the idiomatic Python singleton)

# config.py
_settings = {}

def get_settings():
    if not _settings:
        _settings.update(load_from_disk())
    return _settings

Modules are imported once and cached in sys.modules, so any module-level state is naturally a singleton — every importer sees the same object. This is the simplest, most idiomatic option and is exactly what most "singleton" needs in Python actually call for.

Approach 2: overriding __new__

class Singleton:
    _instance = None

    def __new__(cls, *args, **kwargs):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
        return cls._instance

a = Singleton()
b = Singleton()
a is b   # True

__new__ runs before __init__ and is responsible for actually creating the instance — by returning a cached instance instead of creating a new one, every call to Singleton() returns the same object. Watch out: __init__ still runs every time Singleton() is called (even on the cached instance), so you typically need to guard re-initialization too.

Approach 3: a metaclass

class SingletonMeta(type):
    _instances = {}

    def __call__(cls, *args, **kwargs):
        if cls not in cls._instances:
            cls._instances[cls] = super().__call__(*args, **kwargs)
        return cls._instances[cls]

class Database(metaclass=SingletonMeta):
    pass

This centralizes the singleton logic in one reusable metaclass rather than duplicating __new__ in every class that needs it — useful if you have many singleton classes, at the cost of adding metaclass complexity.

The tradeoff nobody skips: testability

Singletons introduce global mutable state, which makes unit tests harder to isolate (tests can leak state into each other through the shared instance) and makes dependency substitution awkward (you can't easily swap in a fake Database for a test without monkeypatching the singleton).

The more commonly recommended alternative in modern Python code is dependency injection: construct the shared object once (e.g., in main() or an app factory) and pass it explicitly to whatever needs it, rather than having classes reach out and grab a global singleton themselves. This keeps the "there's only one" property where it's genuinely needed (one process, one instance) while keeping tests able to substitute a fresh instance per test.

Interview-ready summary: The simplest, most Pythonic singleton is just a module-level object (modules are already cached singletons); __new__- or metaclass-based singletons work but add complexity. In practice, prefer constructing the shared object once and passing it explicitly (dependency injection) over a true singleton, since global state makes testing harder.

The shape of the problem

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()

D().method()
# D.method
# B.method
# C.method
# A.method

Both B and C inherit from A — so D, which inherits from both, forms a "diamond" (D → B → A, D → C → A). A naive depth-first search would call A.method after B (since B's parent is A), then call A.method again after C — visiting A twice and giving C no chance to run before A does.

How C3 linearization fixes it

D.__mro__ is [D, B, C, A, object] — A appears exactly once, after both B and C. Because every class's super() call resolves against this single shared MRO (not against its own direct parent), the chain D → B → C → A runs each class's method exactly once, in a well-defined order that respects D's declared base order (B before C).

Why this matters practically: cooperative mixins

This is exactly the mechanism that makes mixin composition safe:

class Base:
    def __init__(self):
        print("Base init")

class Mixin1(Base):
    def __init__(self):
        print("Mixin1 init")
        super().__init__()

class Mixin2(Base):
    def __init__(self):
        print("Mixin2 init")
        super().__init__()

class Combined(Mixin1, Mixin2):
    pass

Combined()
# Mixin1 init
# Mixin2 init
# Base init

Base.__init__ runs exactly once, after both mixins — not once per mixin and not skipped. Without C3's guarantee of a single consistent linearization, composing mixins that share a common base would be far more error-prone.

When Python can't resolve it

If the declared base-class orders are mutually contradictory (e.g., one class says B before C, another says C before B, and something inherits from both), C3 has no valid linearization and Python raises TypeError: Cannot create a consistent method resolution order at class definition time, rather than silently picking an arbitrary order.

Interview-ready summary: The diamond problem is the ambiguity of which shared ancestor's method runs, and in what order, when two parent classes share a common base. Python's C3 linearization algorithm computes a single MRO where every ancestor appears exactly once in a consistent order, which is what makes super()-based cooperative multiple inheritance well-defined instead of ambiguous.