Container & context protocols

Syntax is a call in disguise

Python's built-in syntax does not check what type you are. It calls a method and trusts the answer. len(x) is x.__len__(). for v in x is driven by x.__iter__(). v in x tries x.__contains__(v). Implement the method and the syntax starts working on your class, with no inheritance and no registration.

class Deck:
    def __init__(self, cards):
        self._cards = cards

    def __len__(self):
        return len(self._cards)

    def __iter__(self):
        yield from self._cards

    def __contains__(self, card):
        return card in self._cards

deck = Deck(["A", "K", "Q"])
print(len(deck))            # 3
print("K" in deck)          # True
print([c for c in deck])    # ['A', 'K', 'Q']

Three small methods and Deck now behaves like a built-in collection everywhere: comprehensions, sorted(), max(), tuple unpacking, and if deck: all work, because they are all written against these same protocols.

Truthiness comes free, and that is a trap

if deck: has no dunder of its own by default. Python falls back to __len__ and treats zero as false. That is convenient until it is not:

empty = Deck([])
if empty:
    print("has cards")      # never runs, because len(empty) == 0

If your object should always be truthy regardless of size, say so explicitly with __bool__. Otherwise an empty-but-valid object silently behaves like None at every if.

Context managers: guaranteeing the cleanup

with exists so that cleanup runs even when the body raises. __enter__ sets up and returns the value bound by as; __exit__ tears down and receives the exception, if any.

class Timer:
    def __enter__(self):
        self.calls = []
        return self                 # this is what "as t" binds

    def __exit__(self, exc_type, exc, tb):
        self.calls.append("closed")
        return False                # do not swallow exceptions

with Timer() as t:
    t.calls.append("working")
print(t.calls)                      # ['working', 'closed']

__exit__ receives three arguments describing the exception (or three None values on a clean exit). Its return value is a decision: falsy lets the exception propagate, truthy swallows it.

Call stack — with Timer() as t: (body raises)

Step 1 / 5

main

About to enter the with statement.

Pitfalls

• Returning True from __exit__ by accident. A bare return True, or ending with a value that happens to be truthy, silently swallows every exception in the block. Return False (or nothing at all, since None is falsy) unless suppressing is the explicit intent.
• __len__ returning a non-integer. len() raises TypeError if you hand back a float or a string, even when the number is right.
• Forgetting that __len__ drives truthiness. An object with __len__ returning 0 is falsy. Add __bool__ if that is wrong for your type.
• Building a list just to iterate. __iter__ should yield rather than return list(...) when the source is large: yielding streams one item at a time instead of materialising the whole collection.

Interview nuance: this is what "duck typing" concretely means. Python never asks whether Deck inherits from a collection base class; it asks whether Deck answers __len__. That is why collections.abc classes are mostly optional conveniences rather than requirements, and why a mock object that implements the same three dunders is indistinguishable from the real collection at every call site.