Why does `dict.copy()` leave nested lists shared with the original dict?

### What "shallow" actually means A shallow copy creates **one** new object — the outer container — and fills it with references to the exact objects the original held. It copies the structure at the top level and shares everything below it. Every one-level copying idiom in Python behaves this way: * `d.copy()` and `dict(d)` for a dict * `a.copy()`, `a[:]` and `list(a)` for a list * `s.copy()` and `set(s)` for a set * `copy.copy(obj)` for anything, including instances of your own classes Because the inner objects are shared, two different-looking operations on the copy have opposite consequences: ```python import copy original = {"rules": ["velocity", "geo"], "threshold": 83} shallow = original.copy() shallow["threshold"] = 90 # rebinds a key in the new dict only shallow["rules"].append("device") # mutates the list BOTH dicts point at print(original["threshold"]) # 83 print(original["rules"]) # ['velocity', 'geo', 'device'] ``` Rebinding a key touches only the new dict's own slot. Mutating a value reaches through the shared reference. That single distinction — rebind versus mutate — is the whole of shallow-copy behaviour. ### The same rule in disguise The famous grid trap is the identical mechanism written with multiplication: ```python grid = [[0] * 3] * 3 grid[0][0] = 1 print(grid) # [[1, 0, 0], [1, 0, 0], [1, 0, 0]] ``` `[x] * 3` builds a list holding the *same* object three times; it never calls anything to duplicate `x`. The inner `[0] * 3` runs once, and all three rows are that one list. `[[0] * 3 for _ in range(3)]` evaluates the inner expression per iteration and gives three distinct rows. Slicing a list of lists (`rows[:]`) has exactly the same limitation: new outer list, same row objects. For your own classes, `copy.copy(obj)` (with no `__copy__` hook defined) produces a new instance of the same class whose `__dict__` is a shallow copy of the original's — notably **without calling `__init__`**. Any attribute holding a list or a dict is then shared between the two instances, which is the class-shaped version of the same bug. ### When shallow is the right answer Shallow copying is not a defective deep copy; it is the correct and cheap choice whenever the contained values are immutable or intentionally shared: * A dict of strings and numbers — `int`, `str`, `float`, `tuple` of those — cannot be mutated, so sharing them is unobservable and a shallow copy is genuinely independent. * Large read-only reference data that every copy should keep pointing at. Deep-copying it would duplicate megabytes for no behavioural gain. * Snapshotting a set of keys or a working list of items you will only rebind, never mutate in place. The cost difference is real: a shallow copy is proportional to the container's length, while a deep copy is proportional to the size of the entire reachable object graph and allocates a new object for every node in it. ### Making a copy that is actually independent Four options, in rough order of how often they are the right one: 1. **Rebuild with the shape you know.** `{k: list(v) for k, v in d.items()}` or `[row[:] for row in grid]` is explicit, fast and obvious to a reader. Use it when the nesting is one or two known levels deep. 2. **`copy.deepcopy(d)`.** Correct for an arbitrary graph, including shared and cyclic references, but it walks everything and can duplicate far more than you intended. 3. **Make the values immutable.** Store tuples instead of lists, `frozenset` instead of `set`, or frozen dataclass instances. Then a shallow copy is enough forever, and so is no copy at all. 4. **Do not copy — construct.** Often the honest fix is to build the derived structure from its inputs rather than to duplicate and patch an existing one. ### Diagnosing it in a review Two smells are worth reacting to immediately. The first is a defensive copy that is one level too shallow: `self._config = config.copy()` where `config` holds nested lists, which reads as protective but is not. The second is a copy used as a "snapshot" of state that will be mutated element-wise later — a rollback that restores the outer container but leaves the mutated inner objects in place. Both look correct in a diff and only fail when the nested value is actually mutated. A useful mental check while writing the copy: *for each value in this container, would I be upset if someone mutated it through the other reference?* If the answer is no for every value — because they are immutable or deliberately shared — a shallow copy is right. If it is yes for even one, either deep-copy that value specifically or change the design so the value cannot be mutated.