When is `for i in range(len(items))` justified, and what replaces it otherwise?

### What the two loops actually do `for item in items` asks `items` for an iterator (`__iter__`) and pulls values from it one at a time. The loop never computes a position; the sequence hands it the next element directly. `for i in range(len(items))` builds a `range` of integers `0 .. len(items) - 1`, iterates those, and leaves you to fetch each element yourself with `items[i]`. Every pass therefore does extra work: look up the name `items`, subscript it, bounds-check the index. That is real but modest overhead; it is not the main argument. The main argument is intent. A loop that iterates elements says "do this to each element". A loop that iterates positions says "the position matters here" — and when it does not, the reader has to scan the body to discover that it never did. ### When the index is genuinely load-bearing **Writing back into the sequence.** Rebinding the loop variable does nothing to the container: `for x in levels: x = -1` reassigns a local name and leaves `levels` untouched. To mutate in place you need the position. ```python levels = [3, 0, 7, 0, 2] for i in range(len(levels)): if levels[i] == 0: levels[i] = -1 ``` **Relating a position to its neighbours.** Comparing each element with the one before it needs both indexes, and the range's start is what expresses "skip the first, there is nothing before it": ```python jumps = [i for i in range(1, len(readings)) if readings[i] != readings[i - 1]] ``` **Walking part of the positions.** `range(1, len(items))`, `range(0, len(items), 2)` and `range(len(items) - 1)` all say something precise about which positions participate. Trying to express those with direct iteration means reconstructing the index anyway. **Driving a position into something else.** When a second structure is keyed by position rather than by element, the index is the shared key and there is nothing to rewrite. ### The rewrites, and when each applies * **Only the elements matter** — iterate directly: `for item in items:`. * **The element and its position matter** — use `enumerate(items)`, which yields both and keeps the element in a name rather than behind a subscript. * **You are transforming every element into a new sequence** — use a comprehension and rebind: `items = [f(x) for x in items]`. If other references must observe the change, slice-assign the same list object instead: `items[:] = [f(x) for x in items]`. * **You are searching, filtering or aggregating** — the built-ins (`any`, `all`, `sum`, `max`, `min`) usually remove the loop altogether. ### The failure mode people forget `len()` requires the object to define `__len__`. Generator objects and most lazily-produced iterators do not, so `range(len(source))` raises `TypeError: object of type 'generator' has no len()`. Materialising it with `list()` to make the index loop work is exactly the wrong reflex: it defeats the laziness that made the source a generator in the first place. If you truly need positions over a lazy source, `enumerate` works on any iterable and costs nothing. Subscripting has the same precondition: `items[i]` needs `__getitem__`, so an index loop silently assumes a *sequence*, not merely an iterable. Direct iteration works on both. ### The performance question, honestly The index form is slower per pass — an extra global or local lookup, a subscript, a bounds check — but the difference is small enough that it is never the reason to change the code. It is a readability and correctness argument. The two things worth knowing are that `len(items)` is evaluated **once**, before the loop, not on every pass, and that `range` itself costs almost nothing to construct regardless of how large the span is: it holds three integers and computes each value on demand. Note that evaluating `len(items)` once has a consequence: if the loop body changes the length of `items`, the index range no longer matches the container and you can walk off the end or skip positions. Sizing the loop before the loop runs is a promise about the container that the body must keep. ### How to answer this in an interview Do not answer "never use range(len(...))" — that is a slogan, and reviewers who hold it reject correct code. Answer with the rule: **iterate elements by default; introduce an index only when you can name the thing the index is for.** Then give one concrete case where it is right — in-place assignment or a neighbour comparison — and one rewrite you would apply where it is not.