That’s an excellent question.
The key insight is that tuples have no way of knowing whether the objects inside them are mutable. The only thing that makes an object mutable is to have a method that alters its data. In general, there is no way to detect this.
Another insight is that Python’s containers don’t actually contain anything. Instead, they keep references to other objects. Likewise, Python’s variables aren’t like variables in compiled languages; instead the variable names are just keys in a namespace dictionary where they are associated with a corresponding object. Ned Batchhelder explains this nicely in his blog post. Either way, objects only know their reference count; they don’t know what those references are (variables, containers, or the Python internals).
Together, these two insights explain your mystery (why an immutable tuple “containing” a list seems to change when the underlying list changes). In fact, the tuple did not change (it still has the same references to other objects that it did before). The tuple could not change (because it did not have mutating methods). When the list changed, the tuple didn’t get notified of the change (the list doesn’t know whether it is referred to by a variable, a tuple, or another list).
While we’re on the topic, here are a few other thoughts to help complete your mental model of what tuples are, how they work, and their intended use:
-
Tuples are characterized less by their immutability and more by their intended purpose.
Tuples are Python’s way of collecting heterogeneous pieces of information under one roof. For example,
s = ('www.python.org', 80)
brings together a string and a number so that the host/port pair can be passed around as a socket, a composite object. Viewed in that light, it is perfectly reasonable to have mutable components. -
Immutability goes hand-in-hand with another property, hashability. But hashability isn’t an absolute property. If one of the tuple’s components isn’t hashable, then the overall tuple isn’t hashable either. For example,
t = ('red', [10, 20, 30])isn’t hashable.
The last example shows a 2-tuple that contains a string and a list. The tuple itself isn’t mutable (i.e. it doesn’t have any methods that for changing its contents). Likewise, the string is immutable because strings don’t have any mutating methods. The list object does have mutating methods, so it can be changed. This shows that mutability is a property of an object type — some objects have mutating methods and some don’t. This doesn’t change just because the objects are nested.
Remember two things. First, immutability is not magic — it is merely the absence of mutating methods. Second, objects don’t know what variables or containers refer to them — they only know the reference count.
Hope, this was useful to you 🙂