Why is `[0]*n` safe in Python while `[[]]*n` shares one list?

### One rule, two outcomes Sequence repetition has a single rule: `seq * n` builds a new sequence whose slots hold the references already in `seq`'s slots. It never copies the objects behind those references, at any depth. So the question is never *whether* the resulting elements are shared — with `n > 1` and a one-element operand they always are — but whether that sharing is *observable*. Sharing becomes observable only when something can change the shared object in place. That is the whole of the immutable/mutable split. ### Rebinding a slot versus mutating an object Two operations look similar and are not: * `xs[0] = 9` — an index assignment. It changes the *list*: slot 0 now references a different object. Slots 1 and 2 still reference whatever they referenced before. The old object is untouched. * `xs[0].append(1)` — a method call on the *element*. It changes the object that slot 0 references. Every other slot referencing that same object sees the change, because there is only one object. With `xs = [0]*3` you can only ever do the first kind of thing, because `int` exposes no in-place mutation at all: arithmetic returns new integers. So `[0]*3` behaves exactly as if the zeros had been copied, and CPython gets to skip the copying. With `ys = [[]]*3` the second kind is available and is usually what you want to do with a list, which is why the trap fires almost immediately. ### The safe fillers Elements that are immutable all the way down are always safe to repeat: `int`, `float`, `bool`, `str`, `bytes`, `None`, `frozenset`, `range`, and tuples whose own elements are immutable. `[None]*n` and `[0]*n` are the standard way to preallocate a list of known length, and `['-']*width` is the standard way to build a placeholder row. Repeating an immutable *sequence* is safe for a second reason: `'ab'*3` and `(0,)*3` produce a brand-new `str` or `tuple`, and neither the result nor its elements can be mutated, so no aliasing is observable anywhere. ### The unsafe fillers Anything with in-place mutation is unsafe to repeat when you meant 'n independent ones': `list`, `dict`, `set`, `bytearray`, `collections.deque`, `collections.Counter`, and ordinary class instances with settable attributes. `[[]]*n`, `[{}]*n`, `[set()]*n` and `[MyState()]*n` all give you one object under n names. The subtle one is the tuple that is immutable but not *deeply* immutable: `([],)*3` yields three references to a single tuple whose element is a mutable list, so `t[0][0].append(1)` is visible through all three. 'Immutable container' is not the same claim as 'immutable contents'. ### `+` is the same shallowness `xs + ys` also builds a new list holding the existing element references — the outer list is new, the elements are shared. `xs + xs` therefore places each element of `xs` in the result twice. It differs from `xs * 2` only in that you wrote the operand twice; if the operand expression is *evaluated* twice, as in `[[0]*3] + [[0]*3]`, you get two distinct rows, and that is a difference in evaluation, not in the operator's copying behaviour. Augmented assignment is a different question again: `xs = xs * 2` builds a new list and rebinds the name, while `xs *= 2` calls the in-place multiply and extends the existing list, so every other name bound to that list sees it double in length. ### The rule to carry Ask one question at the construction site: *can the repeated element be changed in place?* If no, repetition is a fast, idiomatic preallocation and you should use it. If yes, you almost certainly wanted n independent objects, and only a per-item construction — a comprehension, a loop with `append`, or a factory such as `collections.defaultdict(list)` for the dict case — gives you that. Stating the rule in those terms is what an interviewer is listening for, because it generalises to every place Python hands you a shared reference rather than a copy.