Why write a Python `while True:` loop with an explicit break instead of a real condition?

### The problem the idiom solves A `while` tests its condition at the top of the pass. That is fine when the value being tested already exists, and awkward when the loop's job is to *produce* that value. Reading records until a terminator arrives is the archetype: you cannot test the record before you have read it, and you do not want to process the terminator. Written as a top-tested loop, it comes out like this: ```python line = stream.readline() # read #1 while line and line.strip() != "STOP": print(line.strip()) line = stream.readline() # read #2, must stay identical ``` The body-and-a-half is visible: the read appears twice. Every future change — a different call, an extra strip, an added decode — must be made in both places, and the day the two drift is the day the first record is processed differently from the rest. This is the shape the idiom exists to remove. ### The loop-and-a-half ```python while True: line = stream.readline() if not line or line.strip() == "STOP": break print(line.strip()) ``` Now the read exists once, the stop test sits immediately after it — at the first moment the information exists — and the processing sits after the test. The structure is *read, test, use*, which is also the order the reader thinks in. This is a sentinel-controlled loop: the loop runs until a distinguished value arrives in the data stream, and that sentinel value is consumed by the test rather than processed as data. ### Choosing the sentinel The sentinel must be a value that **cannot occur as real data**, or the loop stops early on a legitimate record. Python's I/O layer is careful about this: a text file object's `readline()` returns the empty string only at end of file, because a genuinely blank line comes back as `"\n"`. The empty string is therefore a safe terminator; `"\n"` would not be. The usual mistake is reaching for `None` when `None` is itself a legal value. A lookup that returns `None` both for "missing" and for "stored as None" cannot terminate a sentinel loop correctly. The fix is a private sentinel object that nothing else can produce: ```python MISSING = object() while True: item = mapping.get(next_key, MISSING) if item is MISSING: break ... ``` `object()` instances are unique and compared with `is`, so no caller-supplied value can be mistaken for the terminator. ### The price, and the discipline that pays it `while True:` moves the termination argument out of the condition and into the body, where a reader has to go looking for it. That is a real loss of local reasoning, and it is why style guidance treats the idiom as a tool rather than a default. Things worth insisting on in review: - **One break, if the loop can be written with one.** Several scattered exits recreate the tangle the idiom was supposed to remove, and make it hard to say what is true when the loop finishes. - **The break near the top.** Read, test, then use. An exit buried thirty lines down is invisible. - **A reachable break.** `while True:` with a `break` on a branch that cannot be taken is an infinite loop with camouflage. Ask what makes the tested value eventually reach the sentinel. - **No redundant flag.** Setting `done = True` *and* breaking, or looping on `while not done:` and also breaking, gives two mechanisms for one decision and lets them disagree. - **A short body.** If the body is long enough that the exit is hard to find, extracting the work into a function usually turns the loop back into something a plain condition can express. ### Alternatives worth knowing A sentinel loop over a repeated zero-argument call has a direct `for` spelling: the two-argument form of `iter()` builds an iterator that calls the function until its result equals the sentinel, so `for line in iter(stream.readline, ""):` replaces the whole `while True` block, and the terminator is stated in the header where a reader expects it. Where the loop is genuinely unbounded — a REPL, a state machine, a supervisor driving until an operator stops it — `while True:` is not a workaround at all but the honest statement of intent, and dressing it up in a flag variable only obscures that. One last note on style: `while True:` and `while 1:` compile to the same thing, and `True` is a keyword in Python 3, so there is no name lookup to save. Write `while True:`; there is no performance argument on the other side.