Interfaces in Python: duck typing, ABCs and Protocols

Python has no interface keyword, and the interview question underneath “how do you define an interface?” is whether you know the three mechanisms it has instead, and which one to reach for. Type-checker mechanics for Protocol are in Protocol and structural typing; this note is the OOP decision.

Three ways to say “anything with a .read()”

Duck typing is the default and the oldest: call .read() and let it raise if the object cannot. It costs nothing and documents nothing. The failure surfaces wherever the method is first used, which may be deep inside a library and long after the wrong object was passed in.

An ABC

An ABC makes the contract explicit and enforced. Subclass it, and forgetting a method fails at instantiation rather than at first use:

from abc import ABC, abstractmethod

class Storage(ABC):
    @abstractmethod
    def read(self, key: str) -> bytes: ...
    @abstractmethod
    def write(self, key: str, data: bytes) -> None: ...

class Broken(Storage):
    def read(self, key): return b""

Broken()   # TypeError: Can't instantiate abstract class Broken
           # with abstract method write

The cost is nominal typing: a class is a Storage only if it inherits from Storage. A third-party class with the right methods is not one, and you cannot change its bases.

A Protocol

A Protocol is the contract without the inheritance. Any object with the right methods satisfies it, checked statically:

from typing import Protocol

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

def load(store: Readable, key: str) -> bytes:
    return store.read(key)

load(boto3.client("s3"), "k")   # type error: no read(key) - caught by mypy
load(MyStore(), "k")            # fine, and MyStore never heard of Readable

That second call is the whole argument. The consumer declares what it needs; the provider does not have to know. This is dependency inversion without an import in either direction, which is why Protocols are the right default for boundaries between packages and for anything you will want to fake in a test.

Choosing

Reach for an ABC when you own the hierarchy and want shared implementation — a base class with a real close() that three subclasses inherit, plus two abstract methods each must fill. abc also gives you register() for declaring a virtual subclass you cannot edit.

Reach for a Protocol when the thing is defined by what it can do rather than what it is: a callback, a repository interface, a plugin, a file-like object. Most “interfaces” in application code are this kind.

Reach for plain duck typing in a script or a function that will never be called with anything else. Adding a Protocol to a ten-line helper is ceremony.

# The plugin case: a Protocol at the boundary, registration by name.
class Exporter(Protocol):
    name: str
    def export(self, rows: list[dict]) -> bytes: ...

EXPORTERS: dict[str, Exporter] = {}

def register(exporter: Exporter) -> Exporter:
    EXPORTERS[exporter.name] = exporter     # type-checked against the shape
    return exporter

The interfaces Python already defines

Most of the language’s own contracts are informal protocols on dunder methods, and collections.abc gives them names you can check against:

isinstance(x, collections.abc.Iterable) works on any class with __iter__ even though it never subclassed anything — the ABC implements __subclasshook__ to check the shape. That is structural typing predating Protocol by a decade, and it is the precedent to cite when someone says Protocols are un-Pythonic.

Where it breaks in production

• isinstance against a Protocol without @runtime_checkable raises. With it, the check only confirms method names exist — not signatures — so a class with read(self) passes for read(self, key) and fails later.
• ABC across a package boundary. The other package must import your base class to inherit from it, coupling their release to yours. A Protocol removes the import.
• Protocol with default implementations. You can put a method body in a Protocol, but implementers only get it if they explicitly subclass the Protocol, which defeats the point. Shared behaviour wants an ABC or a mixin.
• Optional methods. Neither mechanism expresses “has flush() if it can”. Split into two Protocols and check for the narrower one where it matters.
• Duck typing failures deep in a call stack. The AttributeError fires three libraries down from the mistake. A Protocol at the boundary moves that to type-check time.

Related

• Protocol and structural typing - runtime_checkable, generic protocols, the type-checker view.
• Data Abstraction in Python - ABCs as the abstraction tool.
• Magic Methods and Attributes in Python - the dunder methods the built-in protocols are made of.
• Dependency Inversion - the design principle a Protocol at a boundary implements.
• Test doubles taxonomy - faking a Protocol is trivial; faking an ABC hierarchy is not.