@abstractmethod: Requiring Subclasses to Implement a Method Before They Can Be Instantiated

Python's duck typing philosophy means you can call any method on any object and find out at runtime whether it works. That flexibility is powerful, but in larger codebases it creates a problem: nothing stops a developer from subclassing a base class and forgetting to implement a critical method. The error only surfaces when the missing method is called, possibly deep inside production code. The @abstractmethod decorator from the abc module solves this by moving the check to instantiation time. If a subclass has not overridden every abstract method, Python refuses to create an instance and raises a TypeError immediately. The mechanism was introduced in PEP 3119, authored by Guido van Rossum and Talin in 2007, and has been available since Python 2.6 and 3.0.

Setting Up an Abstract Base Classfoundation

An abstract base class (ABC) is a class that cannot be instantiated directly. You create one by inheriting from abc.ABC and decorating one or more methods with @abstractmethod:

from abc import ABC, abstractmethod


class Shape(ABC):
    @abstractmethod
    def area(self) -> float:
        """Calculate and return the area of the shape."""
        ...

    @abstractmethod
    def perimeter(self) -> float:
        """Calculate and return the perimeter of the shape."""
        ...

    def describe(self) -> str:
        return f"{self.__class__.__name__}: area={self.area()}, perimeter={self.perimeter()}"

The Shape class defines two abstract methods (area and perimeter) and one concrete method (describe). The concrete method can call the abstract methods because by the time describe runs, the object is guaranteed to be an instance of a subclass that has implemented both.

What Happens When a Subclass Forgetsfoundation

If a subclass does not override every abstract method, Python blocks instantiation:

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

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

    # perimeter is NOT implemented


try:
    c = IncompleteCircle(5)
except TypeError as e:
    print(f"Error: {e}")

The error names the missing method. This makes debugging straightforward. The class definition itself succeeds — the TypeError is raised only when you try to create an instance. This means you can define intermediate abstract classes that inherit from other abstract classes without implementing all the methods.

Implementing the Abstract Methodfoundation

A complete subclass provides concrete implementations for every abstract method:

import math


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

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

    def perimeter(self) -> float:
        return 2 * math.pi * self.radius


class Rectangle(Shape):
    def __init__(self, width: float, height: float) -> None:
        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)


shapes: list[Shape] = [Circle(5), Rectangle(4, 7)]

for s in shapes:
    print(s.describe())

Both subclasses implement area and perimeter, so they can be instantiated. The inherited describe method works on both because it calls the abstract methods polymorphically.

Abstract Methods Can Have a Bodyfoundation

Unlike abstract methods in Java or pure virtual functions in C++, Python's abstract methods can contain a default implementation. Subclasses must still override them, but they can call the base implementation through super():

import json
from abc import ABC, abstractmethod
from typing import Any


class Serializer(ABC):
    @abstractmethod
    def serialize(self, data: dict[str, Any]) -> str:
        """Base validation shared by all serializers."""
        if not isinstance(data, dict):
            raise TypeError("Data must be a dictionary")


class JsonSerializer(Serializer):
    def serialize(self, data: dict[str, Any]) -> str:
        super().serialize(data)  # run the base validation
        return json.dumps(data, indent=2)


class CsvSerializer(Serializer):
    def serialize(self, data: dict[str, Any]) -> str:
        super().serialize(data)
        headers = ",".join(data.keys())
        values = ",".join(str(v) for v in data.values())
        return f"{headers}\n{values}"


js = JsonSerializer()
print(js.serialize({"name": "Kandi", "role": "engineer"}))

cs = CsvSerializer()
print(cs.serialize({"name": "Kandi", "role": "engineer"}))

Abstract Propertiesfoundation

You can combine @property with @abstractmethod to require subclasses to provide a specific attribute through the property interface. The @abstractmethod decorator must be the innermost (closest to def):

from abc import ABC, abstractmethod


class Vehicle(ABC):
    @property
    @abstractmethod
    def fuel_type(self) -> str:
        """Return the type of fuel this vehicle uses."""
        ...

    @property
    @abstractmethod
    def max_speed_kmh(self) -> int:
        """Return the maximum speed in km/h."""
        ...

    def summary(self) -> str:
        return f"{self.__class__.__name__}: {self.fuel_type}, max {self.max_speed_kmh} km/h"


class ElectricCar(Vehicle):
    @property
    def fuel_type(self) -> str:
        return "electric"

    @property
    def max_speed_kmh(self) -> int:
        return 200


class DieselTruck(Vehicle):
    @property
    def fuel_type(self) -> str:
        return "diesel"

    @property
    def max_speed_kmh(self) -> int:
        return 120


print(ElectricCar().summary())
print(DieselTruck().summary())

Combining with @classmethod and @staticmethodadvanced

You can also require subclasses to implement class methods or static methods. The stacking order matters: @abstractmethod must be the innermost decorator. For a full comparison of how @classmethod and @staticmethod differ, see the dedicated article.

import json
from abc import ABC, abstractmethod
from typing import Any


class Parser(ABC):
    @classmethod
    @abstractmethod
    def from_string(cls, raw: str) -> "Parser":
        """Parse a raw string and return an instance."""
        ...

    @staticmethod
    @abstractmethod
    def file_extension() -> str:
        """Return the file extension this parser handles."""
        ...


class JsonParser(Parser):
    def __init__(self, data: dict[str, Any]) -> None:
        self.data = data

    @classmethod
    def from_string(cls, raw: str) -> "JsonParser":
        return cls(json.loads(raw))

    @staticmethod
    def file_extension() -> str:
        return ".json"


p = JsonParser.from_string('{"key": "value"}')
print(p.data)
print(JsonParser.file_extension())

Multiple Abstract Methodsfoundation

A class can have as many abstract methods as needed. A subclass must implement all of them, or it remains abstract itself. This lets you build layered hierarchies where intermediate classes implement some methods and leave others for further subclasses:

from abc import ABC, abstractmethod


class DataSource(ABC):
    @abstractmethod
    def connect(self) -> None:
        ...

    @abstractmethod
    def fetch(self, query: str) -> str:
        ...

    @abstractmethod
    def close(self) -> None:
        ...


class SqlDataSource(DataSource):
    """Implements connect and close, leaves fetch abstract."""
    def connect(self) -> None:
        print("SQL connection established")

    def close(self) -> None:
        print("SQL connection closed")


# SqlDataSource is still abstract because fetch is not implemented
try:
    SqlDataSource()
except TypeError as e:
    print(f"Still abstract: {e}")


class PostgresSource(SqlDataSource):
    def fetch(self, query: str) -> str:
        return f"Postgres result for: {query}"


pg = PostgresSource()
pg.connect()
print(pg.fetch("SELECT * FROM users"))
pg.close()

Inspecting __abstractmethods__internals

Every class that inherits from an ABC has a __abstractmethods__ attribute — a frozen set of the method names that have not yet been implemented. You can inspect it to see what a subclass still needs to provide:

print(f"Shape requires: {Shape.__abstractmethods__}")
print(f"SqlDataSource requires: {SqlDataSource.__abstractmethods__}")
print(f"PostgresSource requires: {PostgresSource.__abstractmethods__}")

An empty frozenset means all abstract methods have been implemented and the class can be instantiated.

How It Works Under the Hoodinternals

Understanding the internal mechanism explains why certain patterns are required and helps you reason about edge cases. The @abstractmethod decorator is deceptively simple — it does exactly one thing to the function it wraps:

# This is the entire body of abstractmethod() in CPython's abc.py
def abstractmethod(funcobj):
    funcobj.__isabstractmethod__ = True
    return funcobj

That single attribute flag drives the entire enforcement machinery. Here is the chain that follows from it:

1. 01

   @abstractmethod prevents incomplete subclasses from being instantiated: Any class that inherits from an ABC must override every method marked with @abstractmethod. Attempting to create an instance without doing so raises TypeError naming the missing methods.

2. 02

   The mechanism is a single flag: @abstractmethod sets __isabstractmethod__ = True on the function. ABCMeta.__new__ collects flagged names into __abstractmethods__. object.__new__ checks that frozenset at instantiation time.

3. 03

   Inherit from abc.ABC: The simplest way to create an abstract class is to inherit from ABC. This is equivalent to using metaclass=ABCMeta but cleaner.

4. 04

   Abstract methods can have bodies: The base class can provide default logic. Subclasses are still required to override, but they can call super() to reuse the default. This is a deliberate Python design choice documented in PEP 3119.

5. 05

   Stack decorators with @abstractmethod innermost: When combining with @property, @classmethod, or @staticmethod, place @abstractmethod directly above def.

6. 06

   Intermediate abstract classes are valid: A subclass that implements only some abstract methods remains abstract and cannot be instantiated. Further subclasses must complete the remaining methods.

7. 07

   Inspect __abstractmethods__ for debugging: This frozenset on any ABC-derived class shows which methods still need implementation. An empty frozenset means the class is concrete.

8. 08

   ABCs can have __init__: An abstract class can define __init__ for shared setup. Subclass constructors call super().__init__() to run it. The abstract guard only prevents instantiating the ABC directly, not running its constructor code.

9. 09

   register() bypasses @abstractmethod enforcement: Virtual subclasses satisfy isinstance() and issubclass() checks but are not subject to the abstract method guard. Use this for third-party types you cannot modify.

10. 10

    Use update_abstractmethods() for dynamic modification (Python 3.10+): The proper way to recalculate the abstract method set after class creation. Direct assignment to __abstractmethods__ is not supported.

11. 11

    Consider Protocol for structural typing: When you don't want to force inheritance, typing.Protocol (PEP 544, Python 3.8+) checks structure rather than lineage. ABCs enforce via inheritance; Protocols enforce via structural matching.

12. 12

    Choose ABCs for public APIs and large teams: Use @abstractmethod when you want enforcement and discoverability. Use duck typing or Protocol when flexibility and independence from the inheritance tree matters more.

According to PEP 3119, this design was intentional: the check happens at instantiation rather than at class-definition time, so intermediate abstract classes can inherit from other abstract classes without being forced to implement everything immediately.

You can verify the flag directly on any decorated method:

from abc import ABC, abstractmethod


class Renderer(ABC):
    @abstractmethod
    def render(self) -> str:
        ...


# The flag lives on the unbound function object
print(Renderer.render.__isabstractmethod__)  # True
print(Renderer.__abstractmethods__)          # frozenset({'render'})


class HtmlRenderer(Renderer):
    def render(self) -> str:
        return ""


# Once overridden, the name is gone from the frozenset
print(HtmlRenderer.__abstractmethods__)      # frozenset()

Virtual Subclassing with register()advanced

The @abstractmethod enforcement only applies to classes that inherit from the ABC through the normal inheritance chain. Python's ABC machinery also supports a separate concept called virtual subclassing, where a class can be registered as a subclass of an ABC without inheriting from it:

from abc import ABC, abstractmethod


class Drawable(ABC):
    @abstractmethod
    def draw(self) -> str:
        ...


# LegacyWidget does NOT inherit from Drawable
class LegacyWidget:
    def draw(self) -> str:
        return "drawing legacy widget"


# Register it as a virtual subclass
Drawable.register(LegacyWidget)

print(issubclass(LegacyWidget, Drawable))   # True
print(isinstance(LegacyWidget(), Drawable)) # True

# But abstractmethod enforcement does NOT apply to virtual subclasses.
# LegacyWidget is only registered — it can be instantiated even if it
# lacked a draw() method, because @abstractmethod only guards
# classes in the direct inheritance chain.
widget = LegacyWidget()
print(widget.draw())

Virtual subclassing is how the collections.abc module makes built-in types like list and dict satisfy interface checks like isinstance([], collections.abc.MutableSequence) without those types inheriting from user-defined ABCs. As the CPython documentation notes, @abstractmethod only affects subclasses derived through regular inheritance — register() bypasses the enforcement entirely.

Dynamic Modification with update_abstractmethods()advanced

Directly assigning to __abstractmethods__ after a class is created is not supported by the standard machinery. Python 3.10 introduced abc.update_abstractmethods() as the proper, supported way to recalculate the abstract method set for a class after its definition:

# update_abstractmethods() requires Python 3.10+
from abc import ABC, abstractmethod, update_abstractmethods


class Plugin(ABC):
    @abstractmethod
    def execute(self) -> str:
        ...


class ConcretePlugin(Plugin):
    pass  # Missing execute — still abstract


# Dynamically inject a concrete implementation
def _execute(self) -> str:
    return "executed"

ConcretePlugin.execute = _execute  # type: ignore[method-assign]

# Recalculate the frozenset to reflect the new state
update_abstractmethods(ConcretePlugin)

print(ConcretePlugin.__abstractmethods__)  # frozenset()
p = ConcretePlugin()                       # No longer raises TypeError
print(p.execute())

update_abstractmethods() is primarily useful when writing class decorators or metaclass tooling that adds or removes method implementations programmatically. It is available from Python 3.10 onward. In normal application code, you will rarely need it — the standard inheritance pattern handles the common cases.

Abstract Classes vs Duck Typingadvanced

Python developers often debate whether to enforce interfaces with ABCs or rely on duck typing. Both approaches are valid, and the choice depends on the situation. PEP 3119 explicitly addresses this: Guido van Rossum wrote that the introduction of ABCs does not mean the end of duck typing, and that Python would not require classes to inherit from ABCs simply because they implement the same methods.

Can an Abstract Class Have __init__?foundation

Yes — and this trips up many developers. An abstract base class can define __init__ for shared constructor logic, default attributes, or parameter validation. The abstract guard only prevents creating an instance of the ABC itself, not executing its constructor code in a subclass context.

from abc import ABC, abstractmethod


class Connection(ABC):
    def __init__(self, host: str, port: int, timeout: float = 30.0) -> None:
        self.host = host
        self.port = port
        self.timeout = timeout
        self._connected: bool = False

    @abstractmethod
    def connect(self) -> None:
        """Establish the connection."""
        ...

    @abstractmethod
    def send(self, data: bytes) -> None:
        """Send raw bytes."""
        ...

    def disconnect(self) -> None:
        """Shared teardown logic."""
        self._connected = False
        print(f"Disconnected from {self.host}:{self.port}")


class TcpConnection(Connection):
    def connect(self) -> None:
        # calls the shared __init__ automatically via normal inheritance
        print(f"TCP connect to {self.host}:{self.port} (timeout={self.timeout}s)")
        self._connected = True

    def send(self, data: bytes) -> None:
        print(f"TCP send: {len(data)} bytes")


class TlsConnection(Connection):
    def __init__(self, host: str, port: int, cert_path: str, timeout: float = 30.0) -> None:
        super().__init__(host, port, timeout)   # run shared setup
        self.cert_path = cert_path

    def connect(self) -> None:
        print(f"TLS connect using cert: {self.cert_path}")
        self._connected = True

    def send(self, data: bytes) -> None:
        print(f"TLS encrypted send: {len(data)} bytes")


tcp = TcpConnection("db.internal", 5432)
tcp.connect()
tcp.disconnect()

tls = TlsConnection("api.example.com", 443, "/certs/client.pem")
tls.connect()
tls.send(b"GET / HTTP/1.1")

The key insight: TlsConnection.__init__ calls super().__init__() to run the shared setup from Connection, then adds its own cert_path attribute. This is standard cooperative inheritance. The ABC provides the shared structure; each concrete subclass extends or overrides as needed.

Common Mistakesgotcha

These are the errors that appear repeatedly when developers first use @abstractmethod. Each involves a subtle misunderstanding of how the decorator and the ABC machinery interact.

Forgetting to inherit from ABC

The @abstractmethod decorator sets a flag on the function. Nothing happens unless the class inherits from ABC or uses metaclass=ABCMeta. Without it, the decorator is silently ignored and the class instantiates normally.

from abc import abstractmethod

class Animal:          # forgot ABC
    @abstractmethod
    def speak(self):
        pass

a = Animal()           # no error — silently broken
print(a.speak())       # returns None

from abc import ABC, abstractmethod

class Animal(ABC):     # ABC is required
    @abstractmethod
    def speak(self):
        pass

a = Animal()           # TypeError raised correctly

Wrong decorator stacking order

When combining @abstractmethod with @property, @classmethod, or @staticmethod, reversing the order makes the method concrete — Python sees the outer decorator first and the __isabstractmethod__ flag is never propagated.

class Base(ABC):
    @abstractmethod   # wrong: outermost
    @property
    def name(self):
        pass
# Subclass can be created without
# implementing name — silently broken

class Base(ABC):
    @property         # outermost
    @abstractmethod   # innermost — correct
    def name(self):
        pass
# Subclass must implement @property name

Using the deprecated abstractproperty

Before Python 3.3, abc.abstractproperty was the way to declare abstract properties. It was deprecated in 3.3 and should not appear in any code written after that. The correct pattern is stacking @property and @abstractmethod.

isinstance() surprises with ABCs

ABCs modify how isinstance() and issubclass() behave. A class registered with ABC.register() will pass isinstance() checks even though it never inherited from the ABC and has no abstract method enforcement. This can produce unexpected results when you rely on isinstance() for type safety:

from abc import ABC, abstractmethod


class Flyable(ABC):
    @abstractmethod
    def fly(self) -> None:
        ...


class Penguin:
    # Does NOT implement fly — but we register it anyway
    pass


Flyable.register(Penguin)

p = Penguin()
print(isinstance(p, Flyable))   # True  — passes the check
print(hasattr(p, "fly"))        # False — the method doesn't exist

# Calling code that trusts isinstance() will fail:
def launch(thing: Flyable) -> None:
    thing.fly()   # AttributeError at runtime

launch(p)         # register() cannot save you here

The takeaway: register() is a declaration of intent — you are asserting the class conforms to the ABC's interface — not a verification. Use it only when you are certain the registered class does implement the expected behavior.

@abstractmethod vs Protocoladvanced

Python 3.8 introduced typing.Protocol (defined in PEP 544) as a structural alternative to ABCs. Where @abstractmethod enforces an interface through inheritance, Protocol checks structure — if an object has the right methods with the right signatures, it satisfies the protocol regardless of its class hierarchy.

from typing import Protocol, runtime_checkable


@runtime_checkable
class Drawable(Protocol):
    def draw(self) -> str: ...
    def bounding_box(self) -> tuple[float, float, float, float]: ...


# No inheritance needed — any class with these methods qualifies
class Circle:
    def draw(self) -> str:
        return "drawing circle"

    def bounding_box(self) -> tuple[float, float, float, float]:
        return (0.0, 0.0, 10.0, 10.0)


class Square:
    def draw(self) -> str:
        return "drawing square"

    def bounding_box(self) -> tuple[float, float, float, float]:
        return (0.0, 0.0, 5.0, 5.0)


# Both pass isinstance() because @runtime_checkable is set
print(isinstance(Circle(), Drawable))   # True
print(isinstance(Square(), Drawable))   # True

# A static type checker would also accept both in place of Drawable
def render(shape: Drawable) -> None:
    print(shape.draw())

render(Circle())
render(Square())

The practical decision between ABCs and Protocols comes down to this: if you control the class hierarchy and want runtime enforcement, use @abstractmethod. If you want to describe an interface that third-party or built-in types can satisfy without modification, and you want static type checkers to enforce it, use Protocol. The two are not mutually exclusive — a class can satisfy both an ABC and a Protocol simultaneously.

Key Takeaways

1. @abstractmethod prevents incomplete subclasses from being instantiated: Any class that inherits from an ABC must override every method marked with @abstractmethod. Attempting to create an instance without doing so raises TypeError naming the missing methods.
2. The mechanism is a single flag: @abstractmethod sets __isabstractmethod__ = True on the function. ABCMeta.__new__ collects flagged names into __abstractmethods__. object.__new__ checks that frozenset at instantiation time.
3. Inherit from abc.ABC: The simplest way to create an abstract class is to inherit from ABC. This is equivalent to using metaclass=ABCMeta but cleaner.
4. Abstract methods can have bodies: The base class can provide default logic. Subclasses are still required to override the method, but they can call super() to reuse the default. This is a deliberate Python design choice documented in PEP 3119, distinguishing it from Java's abstract methods and C++ pure virtual functions.
5. Stack decorators with @abstractmethod innermost: When combining with @property, @classmethod, or @staticmethod, place @abstractmethod directly above def.
6. Intermediate abstract classes are valid: A subclass that implements only some abstract methods remains abstract itself and cannot be instantiated. Further subclasses must complete the remaining methods.
7. Inspect __abstractmethods__ for debugging: This frozenset on any ABC-derived class shows which methods still need to be implemented. An empty frozenset means the class is concrete.
8. register() bypasses @abstractmethod enforcement: Virtual subclasses satisfy isinstance() and issubclass() checks but are not subject to the abstract method guard. Use this for third-party types you cannot modify.
9. Use update_abstractmethods() for dynamic modification (Python 3.10+): If you need to programmatically add or remove method implementations after class creation, use abc.update_abstractmethods() rather than directly assigning to __abstractmethods__.
10. Choose ABCs for public APIs and large teams: Use @abstractmethod when you want the enforcement and discoverability of a defined interface. Use duck typing when flexibility and simplicity matter more.

The @abstractmethod decorator is Python's mechanism for enforcing interface contracts at the earliest possible moment. It bridges the gap between Python's dynamic nature and the structural guarantees that larger projects need. For more Python tutorials covering decorators, OOP patterns, and the standard library, the full library is available on the home page.