Being used to the old ways of duck typing in Python, I failed to understand the need for ABC (abstract base classes). The help is good on how to use them.
I tried to read the rationale in the PEP, but it went over my head. If I was looking for a mutable sequence container, I would check for
__setitem__, or more likely tried to use it (EAFP). I haven’t come across a real life use for the numbers module, which does use ABCs, but that is the closest I have to understanding.
Can anyone explain to me the rationale, please?
ABCs offer a higher level of semantic contract between clients and the implemented classes.
There is a contract between a class and its callers. The class promises to do certain things and have certain properties.
There are different levels to the contract.
At a very low level, the contract might include the name of a method or its number of parameters.
In a staticly-typed language, that contract would actually be enforced by the compiler. In Python, you can use EAFP or introspection to confirm that the unknown object meets this expected contract.
But there are also higher-level, semantic promises in the contract.
For example, if there is a
__str__() method, it is expected to return a string representation of the object. It could delete all contents of the object, commit the transaction and spit a blank page out of the printer… but there is a common understanding of what it should do, described in the Python manual.
That’s a special case, where the semantic contract is described in the manual. What should the
print() method do? Should it write the object to a printer or a line to the screen, or something else? It depends – you need to read the comments to understand the full contract here. A piece of client code that simply checks that the
print() method exists has confirmed part of the contract – that a method call can be made, but not that there is agreement on the higher level semantics of the call.
Defining an Abstract Base Class (ABC) is a way of producing a contract between the class implementers and the callers. It isn’t just a list of method names, but a shared understanding of what those methods should do. If you inherit from this ABC, you are promising to follow all the rules described in the comments, including the semantics of the
Python’s duck-typing has many advantages in flexibility over static-typing, but it doesn’t solve all the problems. ABCs offer an intermediate solution between the free-form of Python and the bondage-and-discipline of a staticly-typed language.
@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
__subclasshook__ is basically a friendlier API on top of Python’s
__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?)
I find that I rarely need to write my own ABC – I prefer to rely on duck typing – 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
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
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 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"
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.