Mutable and Immutable Values

Part I · Module 2 · Chapter 2.13 · Mutable and Immutable Values

1. The Unanswered Question

Chapter 2.3 established that this does not modify anything:

status = "running"
status = "complete"

The text "running" was not edited. The name was pointed at a different value.

That raises a question the chapter deliberately left alone: could you edit "running" if you wanted to? Not reassign the name — actually change the characters of that value.

2. The Answer, for Everything So Far

No.

name = "abc"
name[0] = "z"

TypeError: 'str' object does not support item assignment

Python is saying: you asked to change a piece of this text, and text does not allow that.

A value that cannot be changed after it is created is called immutable.

Every value type in Module 2 is immutable:

This is why nothing in the module has ever shown a value being modified. There was no way to do it.

3. So How Does Anything Ever Change?

By pointing a name somewhere else. That is the only mechanism you have seen, and for immutable values it is the only one there is.

name = "abc"
name = "zbc"
print(name)

zbc

Nothing was edited. A second value, "zbc", exists, and name refers to it now. The original "abc" is untouched — and if no name refers to it any more, Python simply discards it.

4. What the Alternative Looks Like

To make immutable mean anything, here is a value that is mutable — one that genuinely can be changed in place.

nums = [1, 2, 3]
nums[0] = 99
print(nums)

[99, 2, 3]

The square brackets create a list, which is a value holding several items in order. Module 5 is entirely about them.

The only thing to notice is the contrast: the same shape of instruction that Python refused for text succeeded here. nums was never reassigned — no nums = on the second line — and yet the value it refers to is different afterwards. It was changed in place.

That is what mutable means.

5. Why This Will Matter

Take the two-names experiment from Chapter 2.3, which you understand:

a = 10
b = a
a = 20
print(b)

10

b still refers to 10, because line 3 moved only a.

In Module 5 you will run the same shape of experiment with a mutable value, and the result will be different — not because the name/value model changed, but because a value can be modified without any name being moved. Both names see the change, because there was only ever one value and it was altered.

That is the payoff for the model in Chapter 2.2. Someone carrying the box picture sees the Module 5 result as Python behaving inconsistently. Someone carrying a name refers to a value sees it as the same rule producing a different outcome, because the value itself was different in kind.

You do not need to work that out now. You need to know the distinction exists, so it is not a surprise.

6. Why Immutability Is Useful

It might sound like a limitation. It is largely a safety feature.

Because text and numbers cannot be changed, passing one around is completely safe. Nothing that receives it can alter what you hold. If you have a name referring to "axi_smoke", that value will still be "axi_smoke" for as long as your name refers to it, no matter what else the script does.

That guarantee is worth having, and it is one reason immutable values are the default choice for things like names, statuses and identifiers.

7. Predict, Run, Observe

Predict each — including which fails and with what error.

text = "hello"
text = "world"
print(text)

number = 5
number = 6
print(number)

text[0] = "W"

world
6
TypeError: 'str' object does not support item assignment

The first two succeeded because they are rebinding. The third failed because it is mutation, and text does not permit it. Both reassignments printed before the failure, which is Chapter 1.4 §4 — the shape of the file was fine, so it ran until it hit something impossible.

8. Exercise

Exercise 1 — name the operation. For each, say rebinding or attempted mutation: (a) seed = 4210 then seed = 9999 (b) name = "abc" then name[1] = "x" (c) status = "PASS" then status = "FAIL"

Exercise 2 — cause the error. Write two lines that produce the TypeError from §2. Read the message and say which two words tell you the type involved and the operation refused.

Exercise 3 — explain the untouched value. After these three lines, what does original refer to, and what happened to the value it referred to first?

original = "abc"
copy = original
original = "xyz"

Exercise 4 — predict forward. Without knowing anything about lists, predict what §5 says will be different in Module 5, and say in one sentence why the name/value model still explains it.

9. Summary

• Every value type in Module 2 is immutable — int, float, str, bool, NoneType, complex. None of them can be changed after creation.
• Trying to modify text raises a TypeError. Python refuses rather than quietly making a copy.
• Rebinding is not mutation. Pointing a name at a different value leaves the original untouched; that is all you have done so far.
• Mutable values exist and can be changed in place without any name being reassigned. Lists are the first you will meet, in Module 5.
• The distinction is why the name/value model was worth learning properly. The same rule produces a different outcome when the value itself is a different kind of thing.
• Immutability is a safety property: a value you hold cannot be altered by anything else.

One chapter left in Module 2, and it is about a promise Python does not enforce at all.