Python Abstract Polymorphism: Using ABC for Interfaces

python abstract polymorphism requires a clear understanding of the core syntax, runtime behavior, and practical implementation patterns demonstrated in the examples below.

The Problem: Enforcing a Common Interface Across Classes

In Python, you can pass any object to a function and call a method on it. If the method doesn't exist, you get an AttributeError at runtime. This works fine for small scripts, but as a codebase grows, you often want to guarantee that every class in a family implements the same set of methods. That's where abstract base classes (ABCs) come in. They let you define a contract that subclasses must satisfy, and they enforce it at instantiation time. This is the core of python abstract polymorphism: using an abstract base class to define a common interface, and relying on polymorphic dispatch to call the right implementation.

Defining an Abstract Base Class with abc

The standard library provides the abc module with ABC and abstractmethod. To create an abstract base class, inherit from ABC and decorate methods that subclasses must implement with @abstractmethod. Here's a minimal example:

from abc import ABC, abstractmethod

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

    @abstractmethod
    def perimeter(self) -> float:
        pass

Any class that inherits from Shape must provide concrete implementations of both area and perimeter. If you try to instantiate a subclass that is missing one of them, Python raises TypeError at the moment of instantiation. For example:

class IncompleteShape(Shape):
    def area(self) -> float:
        return 0.0

# Raises TypeError: Can't instantiate abstract class IncompleteShape with abstract method perimeter

This early failure is the main benefit of abstract polymorphism: you catch missing methods before the object is used, rather than when a method is called later.

How Abstract Methods Enable Polymorphism

Once you have a concrete subclass, you can treat it as a Shape anywhere. A function that accepts a Shape can call area() without knowing the concrete type. This is runtime polymorphism: the correct method is dispatched based on the actual object.

class Circle(Shape):
    def __init__(self, radius: float):
        self.radius = radius

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

    def perimeter(self) -> float:
        return 2 * 3.14159 * 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)

def print_area(shape: Shape) -> None:
    print(f"Area: {shape.area()}")

print_area(Circle(2.0))      # Area: 12.56636
print_area(Rectangle(3.0, 4.0))  # Area: 12.0

The print_area function only relies on the Shape interface. It doesn't need to know whether the object is a circle or a rectangle. This is the essence of polymorphism: the same function works with any implementation that satisfies the contract.

Using @abstractmethod with Properties and Class Methods

Abstract methods are not limited to instance methods. You can also mark properties, class methods, and static methods as abstract. The decorator order matters: the @abstractmethod must be innermost, below the property or classmethod decorator.

class Config(ABC):
    @property
    @abstractmethod
    def timeout(self) -> int:
        pass

    @classmethod
    @abstractmethod
    def from_env(cls) -> "Config":
        pass

Subclasses must implement both the property and the class method. This is useful when you want to enforce a configuration interface across different environments, such as development, staging, and production.

Runtime Type Checks with isinstance and issubclass

Abstract base classes also work with isinstance and issubclass. This lets you check whether an object implements the required interface before calling methods. For example:

def describe(shape: object) -> None:
    if isinstance(shape, Shape):
        print(f"Area: {shape.area()}")
    else:
        print("Not a shape")

One subtle feature of ABCs is that you can register a class as a virtual subclass without inheriting from it. This allows duck-typed classes to pass isinstance checks. The register method is available on the ABC:

class Duck:
    def area(self) -> float:
        return 0.0

Shape.register(Duck)
d = Duck()
print(isinstance(d, Shape))  # True

This is useful when you want to integrate third-party classes that already have the right methods but don't inherit from your ABC. However, registration does not require the class to implement all abstract methods; it only affects isinstance and issubclass. Use it with care.

Common Mistakes That Break Abstract Polymorphism

A few pitfalls can undermine the benefits of abstract base classes. The most common is forgetting to inherit from ABC or forgetting to set the metaclass. If you define a class with @abstractmethod but don't inherit from ABC, the decorator has no effect and the class can be instantiated normally. For example:

class BrokenShape:  # missing ABC inheritance
    @abstractmethod
    def area(self) -> float:
        pass

b = BrokenShape()  # No error, but area() is not enforced

Another mistake is implementing only some of the abstract methods. As shown earlier, Python raises TypeError at instantiation if any abstract method is missing. Also, you cannot instantiate the abstract class itself. Trying to do so raises the same TypeError.

Finally, be aware that abstract methods can have a body. The @abstractmethod decorator only marks the method as required; subclasses must override it. If you want to provide a default implementation, you can call super().method() inside the subclass, but the base implementation is not called automatically.

Abstract Polymorphism vs. Duck Typing: Choosing the Right Approach

Python's duck typing means you can always rely on objects having the right methods without any explicit interface. For many small or internal applications, this is perfectly fine. The problem arises when you have a large codebase with many classes that must be interchangeable. Without a common contract, a missing method may only surface in production when a specific code path is executed.

Abstract base classes give you an explicit contract and fail fast at instantiation. They also make the intended interface visible in the code and help type checkers and IDEs. The cost is that you must inherit from the ABC, which couples your classes to a base class. If you are building a library where users can supply their own implementations, an ABC can be a good choice. For a one-off script with two or three similar classes, duck typing is often simpler and more Pythonic.

A practical middle ground is to use ABCs only for public interfaces and rely on duck typing internally. This gives you the safety at the boundaries while keeping the internal code flexible.

Maintainability and Runtime Cost of Abstract Base Classes

Abstract base classes add a small runtime cost at instantiation. When you create an instance of a concrete subclass, Python checks the class's __abstractmethods__ attribute to ensure it is empty. This check is fast and happens only once per instance creation. The overhead is negligible for most applications.

The larger cost is in maintainability. A deep hierarchy of abstract classes can become rigid and hard to change. If you add a new abstract method, every subclass must implement it, which can be a breaking change. This is actually a feature: it forces you to update all implementations when the contract evolves. But it also means you should design the abstract interface carefully before it becomes public.

In practice, abstract polymorphism is most valuable when you have a stable interface and multiple implementations that change independently. It gives you a clear contract, early failure, and better tooling support, all with minimal runtime overhead.