On a Python tuple t = ([1], 2), why does t[0] += [3] raise yet still extend the list?

### Augmented assignment is a read, an update, and a store `x += y` is not one atomic operation. Python compiles it into three steps: evaluate the target to get the current object, run the in-place update on it, then **store the result back into the target**. For a subscript target the expansion is roughly: ```python t[0] = t[0].__iadd__([3]) # what t[0] += [3] means ``` For a mutable object, step two does the real work: `list.__iadd__` is `list.extend` plus `return self`. It mutates the list in place and hands back the very same object. Step three then tries to store that object back into `t[0]` - and if `t` is a tuple, item assignment is not supported, so `TypeError: 'tuple' object does not support item assignment` is raised. Nothing rolls the mutation back. Python has no transaction around a statement; step two already completed and its side effect is permanent. So you get an exception *and* the change: ```python t = ([1, 2], "unchanged") try: t[0] += [3] except TypeError: pass print(t) # ([1, 2, 3], 'unchanged') ``` Disassembling the statement shows the shape plainly: the in-place binary operation runs first, and only then does the store-subscript instruction execute and fail. ### Why the list case is nastier than the int case Write `t[0] += 1` where slot 0 holds an integer and you get the same `TypeError` - but integers have no in-place update, so step two merely computed a new object that is then discarded. The state is untouched and the exception is honest. With a list, the exception is a *lie about what happened*: it reports failure after the visible effect has already landed. That asymmetry is exactly what makes the puzzle worth asking. ### Where it does real damage Picture a subscription-billing run whose per-customer record is a tuple `(adjustments, customer)` with a list of adjustments in slot 0, and a worker that does `record[0] += [credit]` inside a broad `except Exception: continue`. The credit is appended, the store raises, the exception is swallowed, and the loop moves on believing the adjustment was not applied. The retry pass applies it again - so an 11-person team's account is credited twice, and the run reports zero errors because the exception never reached a log. Two defects compound here, and the swallowed exception is the worse of the pair: the language told you precisely what was wrong and the handler threw the message away. The tell in production is a `TypeError` mentioning item assignment on a tuple, or - if it is being swallowed - state that is more mutated than the success path can account for. When you find one, check both sides: fix the statement, and fix the handler that hid it. ### Writing it so it cannot happen * If you mean "extend the list", say so: `t[0].extend([3])` or `t[0].append(3)`. No store back into the tuple is attempted, so nothing raises and the intent is explicit at the call site. * If the record is genuinely meant to change, do not store mutable payloads in a tuple; use a list of lists, or a small mutable class. * If it is genuinely meant to be a frozen record, store immutable items so the mechanism cannot arise at all. * Never catch `TypeError` broadly around data-shaping code. It is nearly always a programming error, not a runtime condition to recover from. ### One distinction to keep straight `t += ([3],)` is a different statement. The target there is the *name* `t`, not a slot inside the tuple. Tuple has no in-place add, so Python falls back to `t = t + ([3],)`, builds a brand-new tuple, and rebinds the name. That succeeds - and it changes nothing about the original tuple object, which other references still see unchanged. ### The one-line interview answer `+=` on a tuple item extends the list in place and only then tries to write the result back into the tuple, which raises - so the exception arrives after the mutation is already visible, and any handler that swallows it leaves half-applied state behind.