Which Python while loops are better rewritten as for loops, and why?

### The distinction that decides it `for` and `while` answer different questions. `for` asks *what do I iterate over* — the pass count is owned by an iterable, and the loop's job is to visit each item. `while` asks *when do I stop* — the pass count is not known up front and is decided by state the body computes. Choosing the wrong one is not a style quibble; each statement removes a class of bug the other allows. ### The rewrite that removes a bug class The most common needless `while` walks a sequence with a hand-maintained cursor: ```python i = 0 while i < len(records): process(records[i]) i += 1 ``` Three separate things must stay in agreement: the initial value, the bound, and the increment. Forget the increment and the loop never ends; put the increment inside an `if` and some elements are visited twice; adjust the bound and you have an off-by-one. Written as `for record in records:` all three vanish, because the iterator protocol owns the position: `for` calls `__next__` on an iterator obtained from the iterable, binds the result, and stops when `StopIteration` is raised. There is nothing left to get wrong about advancing. The same applies to walking a linked structure only if the structure exposes iteration; where it does not, a `while` with an explicit cursor is the honest spelling, and writing `__iter__` for the structure is the real fix if the traversal appears more than once. ### Sentinel loops have a `for` spelling The body-first read loop — `while True:`, read, test, `break` — has a direct translation many Python programmers have never met. The two-argument form of `iter()` takes a callable and a sentinel and returns an iterator that calls the callable with **no arguments** on each pass, raising `StopIteration` as soon as the result equals the sentinel: ```python for line in iter(stream.readline, ""): print(line.rstrip("\n")) ``` The terminator now sits in the loop header, where a reader looks for the stop condition, instead of buried in the body. Note that the sentinel value itself is **not** yielded — it ends the iteration — and that the callable must take no arguments, so a call needing arguments has to be wrapped in a small closure or a `functools.partial` first. The same idiom reads a binary file in fixed-size blocks, drains a queue-like object with a non-blocking getter, or pulls rows from a cursor-style API until it returns its own end marker. `itertools` covers neighbouring shapes: `itertools.count()` gives an unbounded counting iterable when you want a `for` with no upper bound, `itertools.repeat(None, n)` expresses "do this n times" without a throwaway variable, and `itertools.takewhile(predicate, iterable)` turns "consume while this holds" into a `for` header. ### Loops that should stay `while` Rewriting reflexively is its own error. Keep `while` when the termination test genuinely depends on what the body produced: - **Convergence.** Refining an estimate until the change falls under a tolerance has no iterable behind it; the next value is computed from the last. ```python x = 2.0 while abs(x * x - 2.0) > 1e-12: x = (x + 2.0 / x) / 2.0 ``` - **A computed budget.** Consuming until a remaining allowance is exhausted, where each pass subtracts an amount only known after the work. - **State machines.** The next state is chosen inside the body; there is no sequence to iterate. - **Deliberately unbounded loops.** A REPL, an interactive prompt, or a supervisor running until told to stop is an honest `while True:`. A useful test before rewriting: can you name the iterable *without running the body*? If yes, `for` is available and almost always clearer. If naming it requires knowing what the body computes, you are looking at a `while`, and the right investment is making its termination argument visible rather than forcing it into a `for`. ### Why it matters beyond taste The two statements localise different information. A `for` header tells the reader the extent of the loop in one line and guarantees termination whenever the iterable is finite. A `while` header tells the reader the *condition*, and the guarantee has to be reconstructed from the body. Choosing `for` where it fits therefore removes work from every future reader, not just from the person who forgot an increment. Conversely, disguising a genuine `while` as a `for` — iterating over a counting iterable and breaking out on a computed condition — takes the stop test *out* of the header and leaves the worst of both.