Mutable & Immutable

1The whole idea in one question

Mutable means “can be changed”. Immutable means “cannot be changed”. (The im- at the front flips the meaning, exactly like possible and impossible.)

Careful, though — changed means something precise here. It means changed in place: the value that already exists is edited, and it is still the same value afterwards, just different. It does not mean making a new value that looks similar.

2Do not take my word for it — ask Python

Here is a fair test, and you already have the tool for it. In the last lesson you learnt indexing — [0] reaches the first item of any sequence. So far you have only used it to read an item. Now try to write to it:

word = 'hello'

print(word[0])   # reading position 0 — always fine
word[0] = 'H'    # writing to position 0 — is it allowed?

h
Traceback (most recent call last):
  File "immutable.py", line 4, in <module>
    word[0] = 'H'    # writing to position 0 — is it allowed?
    ~~~~^^^
TypeError: 'str' object does not support item assignment

That is the experiment. Store a value in a variable, send it the same instruction — change the item at position 0 — and watch who obeys and who refuses. Three types can be indexed, so three types can be asked: str, tuple and list.

Traceback (most recent call last):
  File "try_string.py", line 2, in <module>
    name[0] = 'R'
    ~~~~^^^
TypeError: 'str' object does not support item assignment

Three values, one instruction, two different answers — discovered rather than memorised. Compare the tuple program with the list program closely: the only difference in the whole file is ( against [. The tuple refused. The list did not even blink.

3The two lists

Here is the classification in full. The good news is that you do not have to memorise both columns — there are only three mutable types in the whole language. Learn those three, and everything else is immutable by default.

4“But I have seen a string change!”

This is the point where everybody objects, so let us settle it. There are two programs that look exactly like a string changing. Neither of them changes a string.

1. A method hands back a new string

word = 'hello'

print(word.upper())   # a new string comes back
print(word)           # the original never changed

HELLO
hello

Did 'hello' change into 'HELLO'? It did not. upper() built a brand new string and handed it back. The original 'hello' is still 'hello', exactly as it was, untouched somewhere in memory.

2. The same name is given a new value

This one is far more convincing, because one name really does print two different things:

s = "hello"
print(s)

s = "bye"
print(s)

hello
bye

So the string changed? No. Nothing was written into the hello box at all. The line s = "bye" is two separate events, and neither of them edits a string:

This is the memory wall from the assignment lesson, and it is the honest picture. Run it line by line and keep your eye on where the label s is:

The word hello is still sitting in memory at the end, letter for letter. Nothing rubbed it out and nothing edited it — it has lost its label, that is all, so no line of your program can reach it any more. (Python tidies away values nothing can reach. Tidying away is not editing.)

And none of this is about strings. Swap in a number and the picture does not change at all — n = 5 then n = 7 gives 7 a box of its own and moves the label n onto it, because the number five cannot become seven. Try the integer and float tabs above and watch the same thing happen. Reassignment works this way for every immutable type.

One more thing follows from all of this, and it is the whole of the next lesson. If a name is only a label, then two labels can sit on one value. Whether that is handy or dangerous depends on exactly what you have just learnt — whether the value can be changed.

5Why does any of this matter?

Try the refusals yourself. Python is very clear about them:

6Recap