Mutable vs Immutable Types in Python

Mutability is about whether the object itself can be changed after it has been created. Lists, dictionaries, sets and bytearrays are mutable. Tuples, strings, bytes, frozensets and numbers are not. When two names point at the same mutable object, a change made through one name is visible through the other name, because both names refer to one single object.

def add_item(items):
    items.append('added')
    return items


original = ['a', 'b']
alias = original
original.append('c')

print(original)           # ['a', 'b', 'c']
print(alias)              # ['a', 'b', 'c']
print(original is alias)  # True

# A tuple has no append, so you build a new one instead.
pair = (1, 2)
pair = pair + (3,)
print(pair)               # (1, 2, 3)
print(len(pair))          # 3

The alias shows the key point, because there is one list object here and two names for it. The tuple lines show the other point. Because a tuple cannot be changed in place, the only way to extend it is to build a new tuple, and then the name is bound to that new tuple.

This distinction is why the words change and rebind matter so much. Mutating a list changes the object that every other reference sees. Rebinding a name only changes which object that one name points at. A list can also be rebound, and when that happens the other names keep on seeing the old object.

That is exactly the mechanism behind the classic bug where a default argument of None or an empty list collects state between calls, and it is also the reason that copy.deepcopy exists for nested structures.

The mutable built-in types are list, dict, set, bytearray and memoryview. The immutable ones are int, float, complex, bool, str, bytes, tuple, frozenset, range and NoneType. Everything else in the standard library follows the same rule. If a type offers an in-place change method such as append, add, update or extend, then it is mutable by its very construction, and if it has no such method then it is not.

The distinction matters in four practical ways.

First, there is aliasing. If two names refer to the same mutable object, then a change made through one is visible through the other. With immutable objects that whole class of bug disappears, which is why a tuple is a good default for a value that should not change.

Second, there is hashability. Only immutable objects that also define a hash can be used as a dictionary key or as a member of a set. A tuple of hashable items works, and that is why a tuple of strings can be a set element while a list cannot.

Third, there is sharing. Passing a mutable object to a function hands over a reference to the same object, so the function is able to change the caller's data. Passing an immutable object effectively passes a value, because the function cannot change it, although the caller can still rebind its own name afterwards.

Fourth, there is thread safety and caching. Immutable data can be shared freely between threads and cached without copying, because nobody is able to change it underneath you. That is why module-level constants in Python are conventionally written as tuples rather than as lists.

The rule for interviews is to treat immutability as a property of the object, and mutability as a property of the reference that points at it. Knowing which built-in types fall on each side is enough to reason about most aliasing bugs.