collections.abc — Abstract Base Classes for Containers¶Added in version 3.3: Formerly, this module was part of the collections module.
Source code: Lib/_collections_abc.py
This module provides abstract base classes that can be used to test whether a class provides a particular interface; for example, whether it is hashable or whether it is a mapping.
An issubclass() or isinstance() test for an interface works in one
of three ways.
A newly written class can inherit directly from one of the abstract base classes. The class must supply the required abstract methods. The remaining mixin methods come from inheritance and can be overridden if desired. Other methods may be added as needed:
class C(Sequence): # Direct inheritance
def __init__(self): ... # Extra method not required by the ABC
def __getitem__(self, index): ... # Required abstract method
def __len__(self): ... # Required abstract method
def count(self, value): ... # Optionally override a mixin method
>>> issubclass(C, Sequence)
True
>>> isinstance(C(), Sequence)
True
Existing classes and built-in classes can be registered as “virtual
subclasses” of the ABCs. Those classes should define the full API
including all of the abstract methods and all of the mixin methods.
This lets users rely on issubclass() or isinstance() tests
to determine whether the full interface is supported. The exception to
this rule is for methods that are automatically inferred from the rest
of the API:
class D: # No inheritance
def __init__(self): ... # Extra method not required by the ABC
def __getitem__(self, index): ... # Abstract method
def __len__(self): ... # Abstract method
def count(self, value): ... # Mixin method
def index(self, value): ... # Mixin method
Sequence.register(D) # Register instead of inherit
>>> issubclass(D, Sequence)
True
>>> isinstance(D(), Sequence)
True
In this example, class D does not need to define
__contains__, __iter__, and __reversed__ because the
in-operator, the iteration
logic, and the reversed() function automatically fall back to
using __getitem__ and __len__.
Some simple interfaces are directly recognizable by the presence of
the required methods (unless those methods have been set to None):
class E:
def __iter__(self): ...
def __next__(self): ...
>>> issubclass(E, Iterable)
True
>>> isinstance(E(), Iterable)
True
Complex interfaces do not support this last technique because an
interface is more than just the presence of method names. Interfaces
specify semantics and relationships between methods that cannot be
inferred solely from the presence of specific method names. For
example, knowing that a class supplies __getitem__, __len__, and
__iter__ is insufficient for distinguishing a Sequence from
a Mapping.
Added in version 3.9: These abstract classes now support []. See Generic Alias Type
and PEP 585.
The collections module offers the following ABCs:
ABC |
Inherits from |
Abstract Methods |
Mixin Methods |
|---|---|---|---|
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|
||
|
Inherited |
||
|
Inherited |
||
|
|
||
|
Inherited |
||
|
|
||
|
Inherited |
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|
||
|
|
||
|
Footnotes
ABC for classes that provide the __contains__() method.
ABC for classes that provide the __hash__() method.
ABC for classes that provide the __call__() method.
See Annotating callable objects for details on how to use
Callable in type annotations.
ABC for classes that provide the __iter__() method.
Checking isinstance(obj, Iterable) detects classes that are registered
as Iterable or that have an __iter__() method,
but it does
not detect classes that iterate with the __getitem__() method.
The only reliable way to determine whether an object is iterable
is to call iter(obj).
ABC for sized iterable container classes.
Added in version 3.6.
ABC for classes that provide the __iter__() and
__next__() methods. See also the definition of
iterator.
ABC for iterable classes that also provide the __reversed__()
method.
Added in version 3.6.
ABC for generator classes that implement the protocol defined in
PEP 342 that extends iterators with the
send(),
throw() and close() methods.
See Annotating generators and coroutines
for details on using Generator in type annotations.
Added in version 3.5.
ABCs for read-only and mutable sequences.
Implementation note: Some of the mixin methods, such as
__iter__(), __reversed__(),
and index() make repeated calls to the underlying
__getitem__() method.
Consequently, if __getitem__() is implemented with constant
access speed, the mixin methods will have linear performance;
however, if the underlying method is linear (as it would be with a
linked list), the mixins will have quadratic performance and will
likely need to be overridden.
Return first index of value.
Raises ValueError if the value is not present.
Supporting the start and stop arguments is optional, but recommended.
Changed in version 3.5: The index() method gained support for
the stop and start arguments.
Deprecated since version 3.12, will be removed in version 3.17: The ByteString ABC has been deprecated.
Use isinstance(obj, collections.abc.Buffer) to test if obj
implements the buffer protocol at runtime. For use
in type annotations, either use Buffer or a union that
explicitly specifies the types your code supports (e.g.,
bytes | bytearray | memoryview).
ByteString was originally intended to be an abstract class that
would serve as a supertype of both bytes and bytearray.
However, since the ABC never had any methods, knowing that an object was
an instance of ByteString never actually told you anything
useful about the object. Other common buffer types such as
memoryview were also never understood as subtypes of
ByteString (either at runtime or by static type checkers).
See PEP 688 for more details.
ABCs for read-only and mutable mappings.
ABCs for mapping, items, keys, and values views.
ABC for awaitable objects, which can be used in await
expressions. Custom implementations must provide the
__await__() method.
Coroutine objects and instances of the
Coroutine ABC are all instances of this ABC.
Note
In CPython, generator-based coroutines (generators
decorated with @types.coroutine) are
awaitables, even though they do not have an __await__() method.
Using isinstance(gencoro, Awaitable) for them will return False.
Use inspect.isawaitable() to detect them.
Added in version 3.5.
ABC for coroutine compatible classes. These implement the
following methods, defined in Coroutine Objects:
send(), throw(), and
close(). Custom implementations must also implement
__await__(). All Coroutine instances are also
instances of Awaitable.
Note
In CPython, generator-based coroutines (generators
decorated with @types.coroutine) are
awaitables, even though they do not have an __await__() method.
Using isinstance(gencoro, Coroutine) for them will return False.
Use inspect.isawaitable() to detect them.
See Annotating generators and coroutines
for details on using Coroutine in type annotations.
The variance and order of type parameters correspond to those of
Generator.
Added in version 3.5.
ABC for classes that provide an __aiter__ method. See also the
definition of asynchronous iterable.
Added in version 3.5.
ABC for classes that provide __aiter__ and __anext__
methods. See also the definition of asynchronous iterator.
Added in version 3.5.
ABC for asynchronous generator classes that implement the protocol defined in PEP 525 and PEP 492.
See Annotating generators and coroutines
for details on using AsyncGenerator in type annotations.
Added in version 3.6.
ABC for classes that provide the __buffer__() method,
implementing the buffer protocol. See PEP 688.
Added in version 3.12.
ABCs allow us to ask classes or instances if they provide particular functionality, for example:
size = None
if isinstance(myvar, collections.abc.Sized):
size = len(myvar)
Several of the ABCs are also useful as mixins that make it easier to develop
classes supporting container APIs. For example, to write a class supporting
the full Set API, it is only necessary to supply the three underlying
abstract methods: __contains__(), __iter__(), and
__len__(). The ABC supplies the remaining methods such as
__and__() and isdisjoint():
class ListBasedSet(collections.abc.Set):
''' Alternate set implementation favoring space over speed
and not requiring the set elements to be hashable. '''
def __init__(self, iterable):
self.elements = lst = []
for value in iterable:
if value not in lst:
lst.append(value)
def __iter__(self):
return iter(self.elements)
def __contains__(self, value):
return value in self.elements
def __len__(self):
return len(self.elements)
s1 = ListBasedSet('abcdef')
s2 = ListBasedSet('defghi')
overlap = s1 & s2 # The __and__() method is supported automatically
Notes on using Set and MutableSet as a mixin:
Since some set operations create new sets, the default mixin methods need
a way to create new instances from an iterable. The class constructor is
assumed to have a signature in the form ClassName(iterable).
That assumption is factored-out to an internal classmethod called
_from_iterable() which calls cls(iterable) to produce a new set.
If the Set mixin is being used in a class with a different
constructor signature, you will need to override _from_iterable()
with a classmethod or regular method that can construct new instances from
an iterable argument.
To override the comparisons (presumably for speed, as the
semantics are fixed), redefine __le__() and
__ge__(),
then the other operations will automatically follow suit.
The Set mixin provides a _hash() method to compute a hash value
for the set; however, __hash__() is not defined because not all sets
are hashable or immutable. To add set hashability using mixins,
inherit from both Set() and Hashable(), then define
__hash__ = Set._hash.
See also
OrderedSet recipe for an
example built on MutableSet.