Abstract base classes — ABC module, `@abstractmethod`

WHAT is an ABC?

WHY do we need them?

Two big wins:

1. Fail early, fail loud — missing methods are caught at instantiation, not later.
2. Self-documenting design — the ABC lists exactly what a subclass owes you.

HOW it works (derivation from first principles)

We don't need to memorise magic — we can build up the behaviour.

Step 1 — A plain base class does NOT enforce anything.

class Shape:
    def area(self):
        raise NotImplementedError   # only fails when CALLED

Why this step? This is the "poor man's ABC". The error only fires when someone actually calls area(). You can still create Shape() and pass it around — the bomb is hidden.

Step 2 — Inherit from ABC + mark the method abstract.

from abc import ABC, abstractmethod
 
class Shape(ABC):
    @abstractmethod
    def area(self):
        ...

Why this step? ABC uses a special metaclass (ABCMeta). When you try Shape(), the metaclass checks an internal set called __abstractmethods__. If it is non-empty, instantiation is blocked immediately.

Step 3 — Watch the enforcement.

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

Why this step? The error now happens at construction time and names the missing method. That's the whole point.

Step 4 — A concrete subclass clears the contract.

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

Why this step? Once Circle overrides area, its __abstractmethods__ set is empty → instantiation allowed.

The mechanism in one sentence

__abstractmethods__ is a frozenset computed automatically by ABCMeta every time a class is defined. Inherited-but-unimplemented abstract methods stay in the set; overridden ones are removed.

Going deeper: combining decorators

Worked example: a payment system

from abc import ABC, abstractmethod
 
class PaymentProcessor(ABC):
    @abstractmethod
    def pay(self, amount): ...
    @abstractmethod
    def refund(self, amount): ...
 
class CardProcessor(PaymentProcessor):
    def pay(self, amount):    return f"Charged {amount} to card"
    def refund(self, amount): return f"Refunded {amount} to card"

Why two abstract methods? The contract says "any processor must both pay AND refund." If CardProcessor only defines pay, __abstractmethods__ still contains refund, so CardProcessor(...) raises TypeError. Step-by-step why: the metaclass subtracts implemented names from the inherited abstract set; refund survives → set non-empty → blocked.

def checkout(p: PaymentProcessor, amt):
    return p.pay(amt)      # safe: ANY subclass guarantees pay() exists

Why this is safe: the type hint + ABC contract means every object reaching checkout provably has pay. No defensive hasattr needed.

Common mistakes (Steel-man each)

Forecast-then-Verify

Flashcards

Connections

• Inheritance and Method Overriding — ABCs rely on overriding to clear the contract.
• Polymorphism — ABCs guarantee a common interface so polymorphic calls are safe.
• Duck Typing vs Nominal Typing — ABCs add nominal (declared) typing on top of duck typing.
• Interfaces in other languages — Java interface / C++ pure virtual = 0 are the analogues.
• Metaclasses and ABCMeta — the machinery that powers __abstractmethods__.
• Protocols (typing.Protocol) — structural alternative to nominal ABCs.

Concept Map

Hinglish (regional understanding)