Why does `b = a` on a Python list leave both names pointing at one object?

### Names are labels, objects are the things Python's execution model separates two ideas that many languages blur. An **object** is a thing that exists in memory: it has a type, a value and an identity. A **name** is an entry in a namespace — a module's globals, a function's locals, an instance's `__dict__` — that refers to an object. The assignment statement `b = a` evaluates the right-hand side to an object and binds the left-hand name to *that same object*. Nothing is duplicated: no list cells, no dict buckets, no bytes. The only thing that changes is that one more name refers to the object, and CPython increments its reference count. That is why the classic surprise happens: ```python a = [1, 2, 3] b = a b.append(4) print(a) # [1, 2, 3, 4] ``` Nobody touched `a`, and yet `a` changed — because there was never a second list to begin with. There is one list object with two labels on it. ### Mutation versus rebinding Two operations look similar on the page and behave completely differently. * `b.append(4)`, `b[0] = 9`, `b.sort()` **mutate** the object both names refer to. Every name bound to that object observes the change. * `b = [9]` **rebinds** the name `b` to a brand-new list. `a` is untouched, because rebinding a name never reaches through to the object the name used to hold. Binding happens in far more places than the `=` sign. Passing an argument binds the parameter name to the caller's object — often described as *call by object reference* or *call by sharing*. A `for` target binds each item in turn. Storing an object in a list, dict or attribute stores the reference. All of them share rather than copy: ```python def add_rule(rules): rules.append("device") # mutates the caller's list def replace_rules(rules): rules = ["device"] # rebinds a local name; caller sees nothing ``` ### Why immutable objects hide the rule A beginner writes `x = 5; y = x; y += 1`, sees `x` unchanged, and concludes that assignment copies. It does not. `int`, `str`, `tuple`, `frozenset` and `bytes` simply have no mutating operations, so sharing one of them is unobservable — `y += 1` had to build a new integer and rebind `y`. The moment a mutable object is shared — a `list`, `dict`, `set`, `bytearray` or an ordinary class instance — the same binding rule becomes visible. The rule never changed; only its observability did. ### Asking for a copy Because assignment never copies, duplication must be requested explicitly: * a list: `list(a)`, `a[:]`, `a.copy()` * a dict: `d.copy()` or `dict(d)` * a set: `s.copy()` or `set(s)` * anything, including your own classes: `copy.copy(obj)` from the `copy` module Each of those produces a **new outer container holding the very same inner objects** — a shallow copy. That is exactly right when the elements are immutable and not enough when they are not; `copy.deepcopy(obj)` walks the whole graph instead. One trap worth memorising: `list(d)` on a dict does not copy the dict at all, it builds a list of its keys. ### Where it bites in real code The most common production shape is an object that hands out its own internal container: ```python class RuleSet: def __init__(self): self._rules = ["velocity", "geo"] def rules(self): return self._rules # the caller can now mutate our state ``` Every caller can `append` into private state, and the resulting bug surfaces far from the code that caused it. Returning `list(self._rules)` or `tuple(self._rules)` makes ownership unambiguous. The mirror image is a constructor that stores a caller's list — `self.items = items` — and is then surprised when the caller keeps mutating it afterwards. Copy on the way in, copy on the way out, or use an immutable value. ### Diagnosing it The symptom is action at a distance: a value changes although nothing nearby touched it. Confirm the alias by comparing identity — `a is b` is true exactly when the two names refer to one object — or by printing `id(a)` and `id(b)`. Then trace backwards to the binding that shared the reference: a bare assignment, an argument pass, a value stored in two places, or a container holding the same object twice. ### The mental model worth keeping Read every assignment aloud as *"bind this name to that object"*, never as *"put the value into the variable"*. Once the second phrasing is gone, aliasing, mutable default arguments, list-of-lists sharing and the whole shallow-versus-deep copy question stop being separate surprises and become one rule showing up in different places.