Which dunder methods make a custom class work with len(), obj[i] and `in`?

## Protocols, not base classes Python's built-in operations are defined in terms of *protocols*: named special methods ("dunders") that the interpreter looks up on an object's **type** and calls on your behalf. `len()`, subscription with square brackets, and the `in` operator are three separate protocols, and a class opts into each one independently by defining the matching method. There is no `Container` base class you are obliged to inherit from; the built-ins never ask "is this a list?", they ask "does this type define the method I need?". That is what people mean when they call Python duck-typed, and it is the reason a class holding its data in a dict, a file, or a remote service can still look and behave like a sequence. ## The size hook: `__len__` `len(obj)` calls `type(obj).__len__(obj)`. The return value must be a non-negative integer: returning a negative number raises `ValueError`, and returning something that is not an integer raises `TypeError`. If the type has no `__len__`, `len()` raises `TypeError: object of type 'X' has no len()`. Two things commonly surprise newcomers. First, `len()` never reads an attribute such as `.length` or `.size` — only the dunder counts. Second, `__len__` does double duty: it is also the fallback used to decide truthiness, so an object with `__len__` returning 0 is falsy in an `if` statement. ## The subscription hooks: `__getitem__`, `__setitem__`, `__delitem__` `obj[key]` calls `__getitem__(key)`, `obj[key] = value` calls `__setitem__(key, value)`, and `del obj[key]` calls `__delitem__(key)`. The *key* is whatever was written between the brackets: an integer for `obj[3]`, a string for `obj['name']`, and a single `slice` object for `obj[1:5]`. Your implementation decides what keys are legal and what to raise when one is not. The convention matters, because other machinery depends on it: sequence-style classes raise `IndexError` for an out-of-range integer, mapping-style classes raise `KeyError` for a missing key. Getting that wrong quietly breaks the legacy iteration fallback described below, and breaks `dict.get`-style patterns built on `try/except KeyError`. ## The membership hook and its two fallbacks `x in obj` is the most layered of the three. Python first looks for `__contains__` and calls it, coercing the result to a bool. If there is no `__contains__`, it iterates the object using `__iter__` and compares each element, using identity first and equality second — the check is effectively `x is element or x == element`. If there is no `__iter__` either, Python drops to the old sequence protocol and calls `__getitem__` with 0, 1, 2 and upward until `IndexError` ends the scan. Only when none of those exist does `x in obj` raise `TypeError`. That chain has two practical consequences. Defining `__contains__` is an *optimisation and a semantics* hook: a set-backed class can answer membership in constant time instead of scanning, and a range-like class can answer arithmetically. And a class that defines only `__getitem__` already supports both `for` loops and `in` without you writing another line — convenient, but worth replacing with a real `__iter__` in production code, because the fallback is slower and only works for integer-keyed objects. ```python class Postings: def __init__(self, doc_ids): self._ids = list(doc_ids) def __len__(self): return len(self._ids) def __getitem__(self, index): return self._ids[index] ``` With just those three methods, `len(p)`, `p[0]`, `p[-1]`, `p[1:3]`, `for d in p`, `9 in p`, `list(p)` and tuple unpacking all work, because each of them is built on the protocols above. ## What it looks like when a hook is missing Each protocol fails on its own terms, and recognising the messages is half of debugging them. Calling `len()` on a type without `__len__` gives `TypeError: object of type 'X' has no len()`. Subscripting without `__getitem__` gives `TypeError: 'X' object is not subscriptable`, while assigning without `__setitem__` gives `TypeError: 'X' object does not support item assignment` — two distinct methods, two distinct errors. And `x in obj` on a type with none of the three membership routes gives `TypeError: argument of type 'X' is not a container or iterable`, whose wording names the fallback chain directly. Notice that these are all `TypeError`: the operation is not merely failing, the type does not implement the protocol at all. ## Why this is the idiomatic route The alternative — subclassing `list` or `dict` — inherits an implementation you may not want and drags in behaviour you then have to override. Implementing the protocol keeps your storage private and your surface deliberate: you expose exactly the operations that make sense for the object. It also composes with static typing and with the abstract base classes in `collections.abc`, which are written in terms of the very same dunders. The interview point is simply this: Python's containers are an interface described by special methods, and any class can implement that interface.