Why does `t[0] += [2]` on `t = ([1],)` raise TypeError yet still extend the list?

### The line is three steps, not one Every augmented assignment compiles to the same shape: **load the target, apply the in-place operation, store the result back into the target**. For a plain local name the store is invisible. For a subscript target it is not, because storing into `t[0]` means calling the container's item assignment. Run `dis.dis("t[0] += [2]")` and the sequence is plain to see: the tuple and the index are loaded, the element is fetched, the in-place binary operation runs, and then a store-to-subscript instruction executes. Three distinct things, in that order, with no transaction around them. ### Why the list grows The element fetched from the tuple is a `list`. `list` implements `__iadd__`, which extends the existing list object with the items of the right-hand iterable and returns `self` — the same object the tuple is still holding. That mutation is complete and permanent the moment the in-place operation returns. ### Why the error is raised anyway The store step then runs. `tuple` implements no item assignment, so the interpreter raises `TypeError: 'tuple' object does not support item assignment`. Python does not undo the earlier mutation, because it has no notion of undoing an arbitrary in-place operation; it does not even know one occurred. ```python t = ([1],) try: t[0] += [2] except TypeError as exc: print("raised:", exc) print(t) # ([1, 2],) - extended anyway ``` ### The immutability that a tuple actually gives you A tuple freezes *which objects* it holds, not the state of those objects. `t[0]` will always be that same list; nothing stops the list itself from changing. Candidates who answer "tuples are immutable, so nothing happened" have confused the container with its contents, and that is exactly the confusion this question is designed to expose. ### The clean forms * `t[0].extend([2])` mutates and never raises: a method call is one step, with no store back into the tuple. * `t[0].append(2)` likewise. * `t = (t[0] + [2],)` builds a new list *and* a new tuple, leaving the original untouched. Note what does **not** help: `t[0] = t[0] + [2]` raises the same `TypeError`, and this time nothing is mutated, because the `+` built a new list that only the failed store would have installed. ### The same trap without a tuple The pattern generalises to any target whose store can fail while the fetched object is mutable. A read-only `property` is the everyday case: ```python class Job: def __init__(self): self._stops = [1] @property def stops(self): return self._stops job = Job() try: job.stops += [2] except AttributeError as exc: print("raised:", exc) print(job._stops) # [1, 2] - mutated before the store failed ``` Here the fetch returns the underlying list, `__iadd__` extends it, and only then does the store fail with `AttributeError` because the property has no setter. Same shape, different exception. A namedtuple field behaves like the tuple case for the same reason. ### And the mirror image, with an immutable element `t = (1,)` then `t[0] += 2` raises the same `TypeError`, but this time nothing at all changed: `int` has no in-place hook, so `__add__` built a new integer that the failed store never installed. Being able to state both halves — mutation-then-failure versus no-mutation-then-failure — is what separates a memorised answer from an understood one. ### What the interviewer is checking Three things, in order of value: that you know augmented assignment ends in a store; that you know the in-place hook has already run and mutated by the time the store fails; and that you do not describe the result as a language bug. It is a direct, unavoidable consequence of two independent rules — in-place operators mutate when they can, and augmented assignment always writes back — meeting in one line.