Why must a custom sequence's `__getitem__` handle negative indexes itself?

### Subscription does no arithmetic When CPython evaluates `obj[key]`, it dispatches to `type(obj).__getitem__(obj, key)` and hands `key` over as an ordinary object. There is no interpreter step that inspects `__len__`, notices a negative integer and rewrites it. A class that defines `__getitem__` therefore receives exactly what was written between the brackets: `obj[-1]` delivers the integer `-1`, and `obj[-3:]` delivers `slice(-3, None, None)` with its `start` still negative. ### Why the built-ins look like they get it for free `list`, `tuple`, `str`, `bytes` and `range` all support `seq[-1]`, and that is where the misconception starts. Each of those types implements the wrap-around inside its own subscription code — it is a property of the type, not of the protocol. Nothing in the language grants that behaviour to a class you write. Some C-level sequence entry points do normalize against the length, which is where the folklore comes from, but the ordinary subscription path that reaches your `__getitem__` does not go through them. ### Delegation hides the bug Most first drafts appear to work, because `__getitem__` simply forwards to a stored list: `return self._items[index]`. The list normalizes, so `-1` behaves. The defect surfaces the moment the class stops delegating — when it computes values from the index, wraps a mapping or a file offset, pages a remote store, or merely bounds-checks with `if not 0 <= index < len(self): raise IndexError(index)`. That last shape is the common one: a perfectly reasonable guard that rejects every negative index a caller writes. ### What a correct `__getitem__` does, in order 1. **Coerce the key** with `operator.index`. It accepts anything implementing `__index__` and raises `TypeError` for a `float` or a `str`, which is exactly what built-in sequences do. `int(key)` is the wrong tool — it would silently truncate `2.7` and happily parse `"2"`. 2. **Wrap**: `if index < 0: index += len(self)`. Do it once, before the bounds check, so `-1` lands on the last valid position and `-len(self)` on the first. 3. **Bounds-check and raise `IndexError`** — not `TypeError`, not `ValueError`, and never return `None`. `IndexError` is the agreed end-of-sequence signal: it is what stops code that walks a sequence by ascending index, and what `reversed()` and iterable unpacking rely on to recognise the end. ### Slices arrive raw too, and the stdlib normalizes them for you A slice object carries whatever the caller typed — negative bounds, `None` for omitted positions, a negative step. `slice.indices(length)` converts all of that into a concrete `(start, stop, step)` triple already clamped to the length: `slice(-3, None, None).indices(5)` returns `(2, 5, 1)`. Feed it to `range()` and you get precisely the positions the caller meant, including the awkward negative-step case. Hand-rolling that arithmetic is the single most common place custom sequences go wrong, because the clamping rules for a negative step are genuinely fiddly. ### The neighbouring dunders inherit the problem `__setitem__` and `__delitem__` take the same key and need the same normalization; a class that fixes only reads will still fail on `obj[-1] = x` or `del obj[-1]`. `__len__` has its own contract alongside: it must return a non-negative integer that fits the platform's index type, or `len()` raises `ValueError` with a message about returning `>= 0`. And because `__bool__` falls back to `__len__` when it is absent, a broken length quietly breaks truthiness as well. ### How to check it in ten seconds You never have to reason about this from memory. A throwaway class whose `__getitem__` simply returns its argument tells you exactly what the subscription machinery delivered: `Probe()[-1]` shows `-1`, and `Probe()[-3:]` shows `slice(-3, None, None)`. The same probe answers every neighbouring question — what an omitted bound becomes, what an `Ellipsis` key looks like, what the tuple subscript `obj[1, 2]` delivers — and building that habit is far more reliable than trusting a remembered rule about which conversions the interpreter supposedly applies on your behalf. ### Why interviewers ask it The question separates people who have *used* the protocols from people who have *implemented* them. The answer is not a fact to memorize but a stance: the data model hands your method the raw request, and every convenience built-in types appear to offer — negative indexing, slice normalization, well-behaved errors — is work those types do for themselves. If your class wants to look like a sequence, it does that work too. A candidate who reaches for `operator.index` and `slice.indices` instead of a hand-rolled `if` chain is signalling they have written this code before and been bitten by its edges. A candidate who insists the interpreter handles it has only ever been on the calling side.