For g = [[]] * 3, why does g[0] += [1] change every row but g[0] = g[0] + [1] not?

### Two operators that look interchangeable On integers, `x += 1` and `x = x + 1` are indistinguishable, because integers are immutable and both forms must produce a new object and rebind the name. On lists they are genuinely different operations, and the difference becomes visible the moment the list is referenced from more than one place — which is exactly what sequence repetition arranges. Start from the setup. `g = [[]] * 3` evaluates the inner empty-list display once and fills three slots with references to that one object, so `g[0] is g[1] is g[2]` is `True`. ### What `g[0] += [1]` does Augmented assignment on a subscript is not a single atomic step. The interpreter fetches the object in slot 0, applies the in-place operation to it, and then stores the result back into slot 0. For a list, the in-place operation is `list.__iadd__`, which extends the list with the items of the right operand and returns **the same object**. So: 1. Fetch the shared list. 2. Mutate it: it now contains `[1]`. 3. Store the returned object — the same one — back into slot 0. Step 2 is what everyone sees, because the mutated object is the object every slot references. Step 3 is a no-op in effect. The result is `[[1], [1], [1]]`. ```pycon >>> g = [[]] * 3 >>> g[0] += [1] >>> g [[1], [1], [1]] >>> g[0] is g[2] True ``` ### What `g[0] = g[0] + [1]` does Here the right-hand side is evaluated first, as an ordinary expression. `list.__add__` does not touch its operands; it allocates a new list holding the concatenation. Assignment then rebinds slot 0 of the outer list to that new object. The original shared list is never mutated, so slots 1 and 2 still show an empty list, and slot 0 no longer shares with them: ```pycon >>> g = [[]] * 3 >>> g[0] = g[0] + [1] >>> g [[1], [], []] >>> g[0] is g[2] False ``` ### Why this matters beyond the puzzle The pair is a precise diagnostic for whether someone understands mutation versus rebinding. `+=` on a mutable object is mutation, and mutation is visible through every reference to that object. Plain `+` followed by assignment is construction plus rebinding, and rebinding is visible only through the name or slot you assigned. Repetition simply guarantees there are other references to be surprised by. It also explains a partial fix that looks like progress. Someone who discovers an aliased grid and "fixes" a row with `g[0] = g[0] + [...]` really does detach row 0 from the others — so the specific symptom they were chasing disappears — while rows 1 and 2 remain a single shared object. The bug is now smaller, rarer and harder to find. Rebuilding every row with a comprehension is the only fix that removes the sharing entirely. ### Performance is the other half of the tradeoff Because `+=` extends in place, it does not copy the existing contents; `list = list + other` allocates and copies the whole left operand every time. In a loop that repeatedly appends to a growing list, the `+` form is quadratic in the total size while the in-place form is linear. So neither operator is simply "the safe one": `+=` is the efficient choice for a list you own exclusively, and `+` is the choice when you must not disturb a list that other references can see. Knowing which situation you are in is the actual skill, and sequence repetition is a reliable way to end up in the second situation without realising it. ### Telling them apart without printing anything The reliable check is identity before and after. Record `id(g[0])`, run the operation, and look again: the in-place form leaves the id unchanged, because the object was mutated rather than replaced, while the concatenating form produces a different id for slot 0. That is a better habit than reading the printed grid, because the printed grid only reveals the difference when the shared object has already been written to, whereas the id tells you which operation you actually performed. The same check distinguishes `extend`-style growth from concatenation anywhere else in a codebase, and it is the fastest way to answer "did this line mutate something other code can see, or build something new?" during a debugging session. ### A related consequence The same in-place-then-store mechanism is why augmented assignment can succeed at mutating and then fail at storing: when the container refuses the store, the mutation has already happened. That interaction belongs with immutable containers, but it is the same two-step model — mutate the object, then store it back — that explains the behaviour here.