Does putting a list inside a Python tuple make that list immutable?

### Names, objects, and what a tuple actually stores Every Python name is a reference to an object, and every container stores references rather than values. A CPython tuple is a fixed-size array of pointers, sized once at construction and never resized. Immutability, at the language level, is exactly one promise: **those pointers never change**. Slot 0 will point at the same object for as long as the tuple lives. The promise says nothing whatsoever about the object on the far end of the pointer. So `t = (['a'], 2)` builds a two-slot tuple whose first slot points at a list. That list is an ordinary mutable object that merely happens to be reachable through `t`. `t[0].append('b')` reads slot 0, gets the list back, and calls a list method on it. The tuple is not consulted, not modified, and not even aware anything happened - the pointer in slot 0 is identical before and after, which is all the tuple ever guaranteed. Printing `t` afterwards shows `(['a', 'b'], 2)` because printing follows the pointer and asks the list to describe itself *now*. ### What genuinely does fail `t[0] = ['c']` raises `TypeError: 'tuple' object does not support item assignment`, and so do `del t[0]` and slice assignment: item assignment requires the type to implement the item-store hook, and tuple deliberately does not. Hold the distinction in your head as **rebinding versus mutating**. Rebinding changes *which* object a slot points at; that is the operation tuple forbids. Mutating changes the object itself; that is entirely the business of that object's own type, and a list says yes. The same reasoning explains a case that surprises people even more: the tuple need not be involved at all. ```python inner = ['a'] t = (inner, 2) inner.append('b') print(t) # (['a', 'b'], 2) ``` Nothing was done *through* the tuple here. The constructor copied a reference, not the list, so the caller still holds a live handle on the tuple's contents. ### Why the language is designed this way Deep freezing would force either recursive copying at construction - turning a cheap pointer copy into an unbounded traversal - or a whole-object-graph freeze concept that Python does not have. Neither fits a type whose selling point is being small and cheap. The chosen contract is the one that can be enforced in constant time: the container's own shape is fixed, and element semantics belong to the elements. ### Consequences that bite in real code **Hashability.** A tuple's hash is derived from its items, so a tuple holding a list cannot be hashed and cannot key a dict or join a set - the shallow-immutability rule showing up as a runtime error. **Defensive copies at boundaries.** A function that accepts a "record" tuple cannot assume nobody else holds a reference to the list inside it. If you need a stable snapshot, copy at the boundary with `copy.deepcopy`, or rebuild the record out of immutable parts. **Frozen record types are just as shallow.** `dataclasses.dataclass(frozen=True)` blocks attribute rebinding, not mutation of a list attribute. `collections.namedtuple` and `typing.NamedTuple` instances *are* tuples and inherit precisely this behaviour, which is why a namedtuple field holding a list is a classic source of surprise shared state. ### How to get real depth when you need it Compose the record from pieces that are themselves immutable: numbers, `str`, `bytes`, other tuples, `frozenset` for set-like fields. Convert on the way in rather than trusting callers: ```python def freeze(value): if isinstance(value, list): return tuple(freeze(v) for v in value) if isinstance(value, set): return frozenset(freeze(v) for v in value) return value ``` For a mapping field, `types.MappingProxyType` gives a read-only *view*, which is weaker again - whoever holds the underlying dict can still change what the view shows. That is the same lesson one level further out: in Python, "you cannot change it" and "it cannot change" are different claims. ### The one-line interview answer Tuple immutability is one level deep. It fixes which objects the tuple refers to, never what those objects contain, so a list inside a tuple stays fully mutable and only rebinding the slot raises.