Why does `lst[:] = items` behave differently from `lst = items` for other holders of that list?

### Names bind, subscripts mutate Python's assignment statement does two entirely different things depending on the target. `name = value` rebinds a name in a namespace — no method on the old object is called, and the old object is completely unaffected. `target[key] = value` is not a binding at all: it is a method call on the container, which is free to change itself. That single distinction explains the whole question. ```python shared = [1, 2, 3] alias = shared shared[:] = [9, 9] # mutates the object both names point at print(alias) # [9, 9] shared = [0] # rebinds the name only print(alias) # [9, 9] -- alias still holds the previous object ``` ### Why it matters in real code Any time a list has more than one holder, the two forms diverge. Picture a coordinator that hands a shared results list to a pool of workers processing a geocoding batch; each worker appends the addresses it resolves. If the coordinator later “resets” the batch with `results = []`, the workers keep appending to the *old* list object, which the coordinator no longer reads. Nothing raises. The batch simply reports zero results, intermittently, depending on when the reset landed — a race on shared state whose root cause is a one-character difference between `results = []` and `results[:] = []`. The same shape appears with a module-level configuration list, a list captured by a closure, or a list held by an object attribute. The rule that follows is worth stating plainly: **if a list is shared, mutating it in place and rebinding the name are different operations with different audiences, and you must choose deliberately.** ### The full in-place vocabulary - `lst[i] = x` replaces one element. - `lst[a:b] = iterable` splices: the target range is removed and the items of the iterable are inserted, so the length may change. The right-hand side may be *any* iterable — a generator, a string, a set — not just a list. - `lst[a:b:step] = iterable` — an *extended* slice — cannot change the length: the iterable must supply exactly as many items as the slice selects, or a `ValueError` is raised. - `del lst[i]` and `del lst[a:b]` remove elements in place. - `lst.clear()` empties the list in place; it is equivalent to `del lst[:]` and to `lst[:] = []`, and has existed since 3.3. - `lst += items` is in-place too — it routes through `extend`, so inside a function it mutates the caller's list, while `lst = lst + items` rebinds the local name and leaves the caller's list alone. ### Cost Slice assignment is O(n) in the elements that move: replacing the whole list touches every slot and releases every old element's reference. Replacing a prefix shifts the untouched tail. It is not a free swap — for a large list, rebinding is the cheap operation and in-place replacement is the one you pay for, which is exactly the opposite of the intuition that “in place must be cheaper”. ### Concurrency caveat `lst[:] = items` is a single statement, and it is tempting to treat it as an atomic swap that other threads can never observe half-done. Do not. Materializing the right-hand side iterates it, which can execute arbitrary Python code; dropping the replaced elements can run their finalizers; and on a free-threaded build — experimental in 3.13 and officially supported in 3.14 under PEP 779 — there is no global lock serializing bytecode at all. If several threads read and write the same list, protect it with a `threading.Lock`, or hand each worker its own list and merge at the end. ### The interview signal This question separates candidates who have internalized Python's names-and-objects model from those who read assignment as “put the value in the variable”. The follow-up is usually the function-argument version: why `def f(x): x = []` cannot clear the caller's list while `def f(x): x[:] = []` can. Both are the same rule seen twice.