How does reversed(obj) decide whether it can reverse a custom object?

## Two routes into `reversed()` The built-in `reversed()` is not a generic algorithm over iterables — it is deliberately narrow, because reversing something requires either the object's cooperation or random access. It tries exactly two routes. **Route one: `__reversed__`.** If the type defines it, `reversed(obj)` calls it and returns the result unchanged. The contract says the method should return a new iterator over the items in reverse, and nothing enforces it: if you return a `list`, `reversed(obj)` hands you that list, `for x in reversed(obj)` still works because a list is iterable, and `next(reversed(obj))` fails with `TypeError: 'list' object is not an iterator`. Return an iterator. **Route two: the sequence protocol.** With no `__reversed__`, `reversed()` requires the object to support integer subscription **and** to have a length. It calls `len(obj)` once, then produces a `reversed` object that yields `obj[n-1]`, `obj[n-2]`, down to `obj[0]`. If neither route is available, you get `TypeError` reporting that the object is not reversible. ## Why this is stricter than iteration This is the detail the question is really about. Forward iteration has its own legacy fallback that needs only `__getitem__` — it starts at index 0 and counts up until `IndexError`. Reversal cannot do that, because it has to know where the end *is* before it can start. So a class defining only `__getitem__` iterates forward happily and fails under `reversed()` — and the error you get is not "not reversible" but `TypeError: object of type 'X' has no len()`, because the missing length is what the fallback tripped on first. Adding `__len__` is the whole fix. ## The length is a snapshot The `reversed` object records the starting index when it is created, not on each step. If you build one and then grow the underlying container, the new items are never visited: ```python r = reversed(container) # start index fixed here container.append("late") # never seen by r ``` Shrinking the container is worse: the walk can index past the new end and raise, or silently skip. As with every iterator in Python, do not mutate the container you are traversing. ## The ABC does not agree with the built-in `collections.abc.Reversible`'s structural check tests for `__reversed__` **and** `__iter__`. So a class with `__len__` and `__getitem__` and nothing else is reversible in practice while `isinstance(obj, collections.abc.Reversible)` returns `False` — the same mismatch that the `Iterable` ABC has with the forward `__getitem__` fallback, for the same reason: the ABCs describe the modern protocols and do not model the compatibility fallbacks. And a class that defines `__reversed__` but no `__iter__` fails that check too, while `reversed()` on it works fine. ## Turning it off Setting a special method to `None` is the documented way to declare an operation unavailable. `__reversed__ = None` in a class body makes `reversed(obj)` raise `TypeError` even when `__len__` and `__getitem__` are both present — useful for a container whose integer keys are identifiers rather than positions, where reversing is meaningless and silently "working" would be worse than an error. The same trick with `__iter__ = None` blocks forward iteration and its `__getitem__` fallback. ## When to write `__reversed__` yourself Most of the time you do not need it — if your class is genuinely index-addressable, the fallback is correct and costs nothing to inherit. Write `__reversed__` when the fallback would be wrong or wasteful: * the underlying storage traverses backwards more cheaply than by index — a doubly linked structure, or a wrapper around a `collections.deque`, where `obj[i]` is not constant-time; * the container is index-addressable but reversing should mean something specific, such as newest-first over a log window; * you want `reversed()` to be lazy over a computed range rather than materializing anything. And remember that `reversed()` never copies. It returns a lazy view that reads the container as you consume it, which is the reason mutation during traversal bites and the reason `list(reversed(x))` is the idiom when you actually want a new reversed list. ## `reversed(obj)` versus `obj[::-1]` The two are not interchangeable and an interviewer may push on the difference. Slicing with a negative step is not a separate mechanism: `obj[::-1]` is one `__getitem__` call with `slice(None, None, -1)`, so it works only if your `__getitem__` handles slice objects, and it returns whatever that method builds — typically a new, fully materialized container of your own type. `reversed(obj)` never touches `__getitem__` with a slice, never allocates the result, and yields items one at a time. Use the slice when you want a reversed copy of the same kind of object; use the built-in when you want to walk backwards without paying for a copy, which on a large container is the difference between constant and linear extra memory.