In the comprehension [x for row in rows for x in row], which for clause is the outer loop?

## The rule: left to right, outermost first A comprehension with more than one `for` clause is defined as a transliteration of nested statements. Read the clauses left to right and write each one as a loop nested inside the previous one; the output expression, which sits at the far *left* of the comprehension, is what executes in the body of the *innermost* loop. So this comprehension: ```python flat = [x for row in rows for x in row] ``` is exactly this statement form: ```python flat = [] for row in rows: # first clause -> outer loop for x in row: # second clause -> inner loop flat.append(x) # output expression -> innermost body ``` The only thing that moves is the output expression, which is written first but evaluated last. Everything else keeps its order. Once you internalise that single rewrite, every multi-clause comprehension becomes readable mechanically rather than by intuition. ## Why this is the flattening idiom Because the outer loop walks the sublists and the inner loop walks their items, appending each item to one result, the expression turns a list of lists into a single flat list. It is the standard one-expression flatten, and it has some useful properties: * **Ragged input is fine.** The sublists need not be the same length, and an empty sublist simply contributes nothing. * **The sublists need not be lists.** Any iterable works — tuples, sets, ranges, generators — because the inner clause only requires something iterable. * **The outer object need not be a list** either; it just has to be iterable. ## It flattens exactly one level This is the misconception that shows up most often. `[x for row in rows for x in row]` removes **one** level of nesting. Given `[[1, 2], [3]]` you get `[1, 2, 3]`; given `[[[1, 2]], [[3]]]` you get `[[1, 2], [3]]` — still nested. Each extra level costs another `for` clause, and by three clauses the expression is usually harder to read than the loop it replaces. For a structure of unknown or mixed depth, a comprehension is the wrong tool: write a small recursive generator function that yields leaves and recurses into anything iterable, with an explicit stopping rule for strings so they are not exploded into characters. That string case is worth its own warning. A `str` is iterable, and iterating it yields one-character strings, so flattening a list of words gives you a list of letters. A `bytes` object is iterable too, and iterating it yields **integers**, not one-byte objects — so the same code over decoded text and over raw bytes produces two very different results. ## The reversed-order bug A clause may only reference names bound by clauses to its left, because those clauses are the enclosing loops. Writing `[x for x in row for row in rows]` raises `NameError: name 'row' is not defined`: the first clause tries to iterate `row`, which nothing has bound yet. The error is loud and immediate, which is a small mercy — but the fix is not to shuffle the clauses until it runs, it is to write the nested statements out and translate them back. ## Alternatives and what they cost * `list(itertools.chain.from_iterable(rows))` produces the same flat list, consuming the sublists one at a time. * An explicit loop calling `list.extend` per sublist is equally clear and often the most readable option when there is any surrounding logic. * `sum(rows, [])` also flattens, and should be avoided: it builds a new intermediate list on every step, so it is quadratic in the total number of items. `functools.reduce` with list concatenation has the same defect. ## Same syntax, other brackets The identical clause ordering applies to the dict, set and generator forms — `{x for row in rows for x in row}` deduplicates while flattening, and swapping the brackets for parentheses gives the generator form of the same nesting. The nesting rule does not change with the bracket; only what is built from the innermost body does. ## Interview framing Interviewers ask this because it separates people who have memorised the flatten one-liner from people who can derive it. The strong answer is the rewrite: state that the clauses map onto nested `for` statements in written order, produce the four-line loop version, then note the one-level limit and the readability ceiling at two clauses.