Why use Abstract Base Classes in Python?

It will make determining whether an object supports a given protocol without having to check for presence of all the methods in the protocol or without triggering an exception deep in “enemy” territory due to non-support much easier.

@Oddthinking’s answer is not wrong, but I think it misses the real, practical reason Python has ABCs in a world of duck-typing.

Abstract methods are neat, but in my opinion they don’t really fill any use-cases not already covered by duck typing. Abstract base classes’ real power lies in the way they allow you to customise the behaviour of isinstance and issubclass. (__subclasshook__ is basically a friendlier API on top of Python’s __instancecheck__ and __subclasscheck__ hooks.) Adapting built-in constructs to work on custom types is very much part of Python’s philosophy.

Python’s source code is exemplary. Here is how collections.Container is defined in the standard library (at time of writing):

class Container(metaclass=ABCMeta):
    __slots__ = ()

    @abstractmethod
    def __contains__(self, x):
        return False

    @classmethod
    def __subclasshook__(cls, C):
        if cls is Container:
            if any("__contains__" in B.__dict__ for B in C.__mro__):
                return True
        return NotImplemented

This definition of __subclasshook__ says that any class with a __contains__ attribute is considered to be a subclass of Container, even if it doesn’t subclass it directly. So I can write this:

class ContainAllTheThings(object):
    def __contains__(self, item):
        return True

>>> issubclass(ContainAllTheThings, collections.Container)
True
>>> isinstance(ContainAllTheThings(), collections.Container)
True

In other words, if you implement the right interface, you’re a subclass! ABCs provide a formal way to define interfaces in Python, while staying true to the spirit of duck-typing. Besides, this works in a way that honours the Open-Closed Principle.

Python’s object model looks superficially similar to that of a more “traditional” OO system (by which I mean Java*) – we got yer classes, yer objects, yer methods – but when you scratch the surface you’ll find something far richer and more flexible. Likewise, Python’s notion of abstract base classes may be recognisable to a Java developer, but in practice they are intended for a very different purpose.

I sometimes find myself writing polymorphic functions that can act on a single item or a collection of items, and I find isinstance(x, collections.Iterable) to be much more readable than hasattr(x, '__iter__') or an equivalent try...except block. (If you didn’t know Python, which of those three would make the intention of the code clearest?)

That said, I find that I rarely need to write my own ABC and I typically discover the need for one through refactoring. If I see a polymorphic function making a lot of attribute checks, or lots of functions making the same attribute checks, that smell suggests the existence of an ABC waiting to be extracted.

_{*without getting into the debate over whether Java is a “traditional” OO system…}

---

Addendum: Even though an abstract base class can override the behaviour of isinstance and issubclass, it still doesn’t enter the MRO of the virtual subclass. This is a potential pitfall for clients: not every object for which isinstance(x, MyABC) == True has the methods defined on MyABC.

class MyABC(metaclass=abc.ABCMeta):
    def abc_method(self):
        pass
    @classmethod
    def __subclasshook__(cls, C):
        return True

class C(object):
    pass

# typical client code
c = C()
if isinstance(c, MyABC):  # will be true
    c.abc_method()  # raises AttributeError

Unfortunately this one of those “just don’t do that” traps (of which Python has relatively few!): avoid defining ABCs with both a __subclasshook__ and non-abstract methods. Moreover, you should make your definition of __subclasshook__ consistent with the set of abstract methods your ABC defines.

A handy feature of ABCs is that if you don’t implement all necessary methods (and properties) you get an error upon instantiation, rather than an AttributeError, potentially much later, when you actually try to use the missing method.

from abc import ABCMeta, abstractmethod

# python2
class Base(object):
    __metaclass__ = ABCMeta

    @abstractmethod
    def foo(self):
        pass

    @abstractmethod
    def bar(self):
        pass

# python3
class Base(object, metaclass=ABCMeta):
    @abstractmethod
    def foo(self):
        pass

    @abstractmethod
    def bar(self):
        pass

class Concrete(Base):
    def foo(self):
        pass

    # We forget to declare `bar`


c = Concrete()
# TypeError: "Can't instantiate abstract class Concrete with abstract methods bar"

Example from https://dbader.org/blog/abstract-base-classes-in-python

Edit: to include python3 syntax, thanks @PandasRocks

Abstract methods make sure that whatever method you are calling in the parent class, has to also appear in the child class. Below are normal ways of calling and using abstract.
The program is written in python3

Normal way of calling:

class Parent:
    def method_one(self):
        raise NotImplemented()

    def method_two(self):
        raise NotImplementedError()

class Son(Parent):
   def method_one(self):
       return 'method_one() is called'

c = Son()
c.method_one()

‘method_one() is called’

c.method_two()

NotImplementedError

With Abstract method:

from abc import ABCMeta, abstractmethod

class Parent(metaclass=ABCMeta):
    @abstractmethod
    def method_one(self):
        raise NotImplementedError()
    @abstractmethod
    def method_two(self):
        raise NotImplementedError()

class Son(Parent):
    def method_one(self):
        return 'method_one() is called'

c = Son()

TypeError: Can’t instantiate abstract class Son with abstract methods method_two.

Since method_two is not called in child class we got error. The proper implementation is below:

from abc import ABCMeta, abstractmethod

class Parent(metaclass=ABCMeta):
    @abstractmethod
    def method_one(self):
        raise NotImplementedError()
    @abstractmethod
    def method_two(self):
        raise NotImplementedError()

class Son(Parent):
    def method_one(self):
        return 'method_one() is called'
    def method_two(self):
        return 'method_two() is called'

c = Son()
c.method_one()

‘method_one() is called’

ABC’s enable design patterns and frameworks to be created. Please see this pycon talk by Brandon Rhodes:

Python Design Patterns 1

The protocols within Python itself (not to mention iterators, decorators, and slots (which themselves implement the FlyWeight pattern)) are all possible because of ABC’s (albeit implemented as virtual methods/classes in CPython).

Duck typing does make some patterns trivial in python, which Brandon mentions, but many other patterns continue to pop up and be useful in Python, e.g. Adapters.

In short, ABC’s enable you to write scalable and reusable code. Per the GoF:

1. Program to an interface, not an implementation (inheritance breaks encapsulation; programming to an interface promotes loose-coupling/inversion of control/the "HollyWood Principle: Don’t call us, we’ll call you")

2. Favor object composition over class inheritance (delegate the work)

3. Encapsulate the concept that varies (the open-closed principle makes classes open for extension, but closed for modification)

Additionally, with the emergence of static type checkers for Python (e.g. mypy), an ABC can be used as a type instead of Union[...] for every object a function accepts as an argument or returns. Imagine having to update the types, not the implementation, every time your code base supports a new object? That gets unmaintainable (doesn’t scale) very fast.