Python Abstract Classes (ABC)

3Python Abstract Classes: explained step by step

In the inheritance lesson, Shape.area() returned 0 so that children could override it. That hides a quiet flaw: if someone writes a new Triangle and forgets area(), nothing complains. The triangle just reports an area of 0, and you discover the bug far away from the line that caused it.

An abstract class closes that gap. It is a parent class that says what every child must be able to do and leaves how to the children. Unlike a placeholder method, the promise is enforced by Python.

When a parent is only a promise

Some parents are never meant to be used on their own. There is no such thing as "just a shape", only circles, squares and triangles. There is no "just a payment method", only cards, bank transfers and vouchers. The parent exists to state a contract: every Shape has an area(), every PaymentMethod can pay(amount), every Exporter can export(rows). Code that knows only the contract can then work with any child, including ones written next year.

Your first abstract class

Inherit from ABC (short for Abstract Base Class) and put @abstractmethod above each method the children must provide. The body is usually just a docstring, because it is not meant to do the work:

from abc import ABC, abstractmethod

class Shape(ABC):
    @abstractmethod
    def area(self):
        """Every shape must say how to work out its area."""

class Square(Shape):
    def __init__(self, side):
        self.side = side

    def area(self):
        return self.side ** 2

print(Square(4).area())

try:
    Shape()
except TypeError:
    print("Cannot create a Shape: it is abstract")

Shape() fails because area() has no real code yet. In Python 3.13 the message reads TypeError: Can't instantiate abstract class Shape without an implementation for abstract method 'area'. Notice when it happens: the moment you try to create the object, not later when some distant code calls area().

Every abstract method must be filled in

A child becomes concrete, meaning you may create objects from it, only when it replaces every abstract method with a real one. If it fills in just some, it is still abstract and fails in the same way. That is the safety net you want when a teammate adds a new subclass and forgets a method. Each abstract class also keeps the names still missing in __abstractmethods__, which is handy for debugging:

from abc import ABC, abstractmethod

class PaymentMethod(ABC):
    @abstractmethod
    def pay(self, amount):
        """Take the money and return a receipt line."""

    @abstractmethod
    def refund(self, amount):
        """Give the money back and return a receipt line."""

class CardPayment(PaymentMethod):
    def pay(self, amount):
        return f"Charged ${amount} to the card"

    def refund(self, amount):
        return f"Returned ${amount} to the card"

class GiftVoucher(PaymentMethod):
    def pay(self, amount):
        return f"Used ${amount} of voucher"

print(CardPayment().pay(30))

try:
    GiftVoucher()
except TypeError:
    print("GiftVoucher is still abstract")

print(sorted(GiftVoucher.__abstractmethods__))

Abstract classes can still hold real code

Being abstract does not change anything else about a class. It can have an __init__, attributes and ordinary methods, and its children inherit them unchanged. Only the methods marked @abstractmethod have to be replaced.

The template method pattern

This is where abstract classes really pay off. Write one concrete method that fixes the order of the steps, and make the individual steps abstract. The parent owns the recipe; each child supplies its own ingredients. Below, export() never changes, but what a header and a row look like is decided by the child:

from abc import ABC, abstractmethod

class Exporter(ABC):
    def __init__(self, title):
        self.title = title

    def export(self, rows):
        lines = [self.header()]
        for row in rows:
            lines.append(self.format_row(row))
        return "\n".join(lines)

    @abstractmethod
    def header(self):
        """First line of the output."""

    @abstractmethod
    def format_row(self, row):
        """One output line for one row."""

class CsvExporter(Exporter):
    def header(self):
        return "name,price"

    def format_row(self, row):
        return f"{row[0]},{row[1]}"

class MarkdownExporter(Exporter):
    def header(self):
        return f"# {self.title}"

    def format_row(self, row):
        return f"- {row[0]}: ${row[1]}"

rows = [("Lamp", 24.5), ("Mug", 8)]
print(CsvExporter("Stock").export(rows))
print(MarkdownExporter("Stock").export(rows))

Nothing in export() knows about CSV or Markdown, so adding a JsonExporter later would not touch it.

Abstract properties

A property can be abstract too, which forces children to provide a value instead of a method. Stack the decorators in this order: @property on the outside and @abstractmethod directly above the def.

from abc import ABC, abstractmethod

class Employee(ABC):
    def __init__(self, name):
        self.name = name

    @property
    @abstractmethod
    def monthly_pay(self):
        """Each kind of employee works its pay out differently."""

    def summary(self):
        return f"{self.name} earns {self.monthly_pay} a month"

class Salaried(Employee):
    def __init__(self, name, salary):
        super().__init__(name)
        self.salary = salary

    @property
    def monthly_pay(self):
        return self.salary

class Hourly(Employee):
    def __init__(self, name, rate, hours):
        super().__init__(name)
        self.rate = rate
        self.hours = hours

    @property
    def monthly_pay(self):
        return self.rate * self.hours

print(Salaried("Asha", 3200).summary())
print(Hourly("Ben", 20, 150).summary())

isinstance() and abstract classes

An abstract class works as a type for everything that keeps its promise, so isinstance(obj, Shape) is True for every child. A function can use that to check its input once, at the door.

from abc import ABC, abstractmethod

class Shape(ABC):
    @abstractmethod
    def area(self):
        """Return the area."""

class Square(Shape):
    def __init__(self, side):
        self.side = side

    def area(self):
        return self.side ** 2

class Tile:
    def area(self):
        return 9

for thing in [Square(2), Tile()]:
    print(type(thing).__name__, isinstance(thing, Shape), thing.area())

ABC or duck typing?

Tile has no Shape parent, yet its area() works, so any code that just calls .area() is happy with it. That is duck typing: "if it has the method, it can do the job". It needs no base class and it is Python's default style.

Reach for an abstract class when: - you own a family of classes and want a forgotten method to be an error at creation time, not a crash halfway through the program; - the children share real code, such as a template method or a common __init__; - you want isinstance() to mean "this object keeps the contract".

Stay with duck typing when only one or two functions use the objects, when the classes come from different libraries you cannot change, or when a base class would add ceremony without any shared code.

One limit to remember: Python only checks that the names exist. It does not check the parameters or whether the method does anything sensible, so a child that defines area(self, extra) still slips through.