Augmented Assignment Surprises

### One syntax, two outcomes `lst += [4]` and `n += 1` are compiled the same way. Python evaluates the target, applies an in-place binary operation, and then **stores the result back into the target**. The store always happens — that detail matters later. What differs between the two lines is whether the operation produced a brand-new object or handed back the object you started with. ### The in-place hook For `x += y` the interpreter first looks for `__iadd__` on `type(x)`. `list` defines it. `list.__iadd__` behaves like `list.extend`: it appends the items of the right-hand iterable onto the existing list object and returns `self`. The store that follows therefore rebinds the name to the very object it was already bound to, which is a no-op. All you observe is that the list grew. `int`, `str` and `tuple` define no `__iadd__` at all. With no in-place hook, Python falls back to the ordinary `__add__` (and, failing that, the right operand's `__radd__`). Neither can mutate an immutable object, so a new object is built and the store rebinds the left-hand name to it. All you observe is that one name now points somewhere else. ### Aliasing is the tell The difference is invisible until a second reference exists: ```python a = [1, 2] b = a a += [3] print(b) # [1, 2, 3] - same object, mutated n = 5 m = n n += 1 print(m) # 5 - n was rebound, m still points at 5 ``` The same asymmetry shows up wherever the reference lives somewhere other than a local name: an attribute on an instance, a module-level list, an element of another list, or a parameter inside a function. ```python def add_all(target, items): target += items # mutates the caller's list def add_all_copy(target, items): target = target + items # rebinds a local; caller sees nothing ``` The second function is almost always a bug when the caller expected an effect, and the first is almost always a bug when the caller did not. ### `+=` on a list is not `+` on a list Because they take different paths, the two operators differ in more than aliasing: * `+=` accepts **any iterable** on the right, because it goes through the extend path: `x = [1]; x += (2, 3)` and `x += "ab"` both work. `+` demands another list — `[1] + (2,)` raises `TypeError`. * `+` builds a new list of the combined length. Building a list by repeated `a = a + [i]` inside a loop copies everything on every iteration and is quadratic; `a += [i]` (or `a.append(i)`) is linear. On a few thousand items the gap is already an order of magnitude. * `+` gives you a fresh object, which is exactly what you want when the input must not be disturbed. ### Strings and the concatenation-in-a-loop trap `s += "x"` semantically rebinds, because `str` is immutable. CPython carries an optimisation that can resize the buffer when the string has only one reference, but that is an implementation detail you must not build on: the portable and predictable way to join many pieces is to collect them in a list and call `str.join` once. ### The other in-place operators follow the same rule `|=` on a `dict` merges in place and mutates (added in Python 3.9); `|=` on a `set` mutates; `|=` on a `frozenset` rebinds, because `frozenset` is immutable. `+=` on a `tuple` rebinds. The question is never "which operator?" but "does this type have an in-place hook, and does anything else hold a reference to the object?" ### The mental model to state in an interview Augmented assignment is *mutate-if-you-can, otherwise-rebind, then-store*. If the target's type can mutate itself, the store is a formality and every holder of that object observes the change. If it cannot, a new object appears and only the name on the left moves. Say those two sentences and you have answered the question; add "and the store still happens either way" and you have set yourself up for the tuple-element follow-up an interviewer will almost certainly ask next.