Dynamic Typing: Names Do Not Have Types

Part I · Module 2 · Chapter 2.12 · Dynamic Typing: Names Do Not Have Types

1. Two Facts You Already Have

From Chapter 2.2: a name refers to a value, and assignment can point it somewhere else.

From Chapter 2.10: a type belongs to a value — type(4210) asked the value what it was.

Put those together and a consequence appears that nobody has yet stated.

2. The Consequence

count = 5
print(type(count))

count = "five"
print(type(count))

<class 'int'>
<class 'str'>

The same name reported two different types, because it was pointed at two different values. Python did not complain, warn, or require anything to be declared.

This property is called dynamic typing.

3. Saying It Accurately

Dynamic typing is regularly described in a way that is wrong, so here is the careful version.

Wrong: "Python variables have no type."

Wrong: "Python doesn't have types."

Right: "Values have types. Names do not. A name can be reassigned to a value of any type."

Python's types are real and they are enforced. Chapter 2.11 showed int("n/a") raising an error rather than guessing, and Chapter 2.9 showed text refusing to behave as a number. Python is strict about what you may do with a value.

What it does not do is require you to declare, in advance, which types a name will ever refer to.

4. Why This Is Convenient

The obvious benefit: less ceremony. You write seed = 4210 rather than declaring a type first, and short scripts get written faster.

The more interesting benefit shows up in conversion:

seed_text = "4210"
seed = int(seed_text)

Two names, two types, no declarations, no casting syntax. Chapter 2.11's conversions read naturally precisely because names are not committed to a type.

5. Why It Needs Discipline

Now the half that matters for anything you will maintain.

Python permits this:

result = 5
result = "five"
result = None
result = 500.0

Every line is legal. And a reader arriving at line 40 of that file has no way to know what result refers to without tracing every assignment above it.

There is an important distinction here, though, and it is worth being precise about.

Reasonable — the name keeps one meaning, and the type change is a deliberate, one-way conversion:

seed_text = "4210"
seed = int(seed_text)

Two names. Each keeps its meaning. The type difference is the whole point.

Unreasonable — one name, two meanings:

seed = "4210"
seed = int(seed)

This works, and it is the version you will see in real code. It reuses one name for the text form and the number form, which means the type of seed depends on which line you are looking at. In three lines that is survivable. In a fifty-line function it is how people lose an afternoon.

6. The Habit

Let a name mean one thing for its whole life.

If a value needs converting, give the result its own name — seed_text and seed, runtime_text and runtime_s. It costs one extra name and it means a reader can trust what they see.

This is the same argument as Chapter 2.4's naming discipline, one level up: there, a good name told the reader what the value is; here, a stable name lets them believe it.

7. What Is Deferred

Python does have a way to write down what type a name is expected to refer to. It is optional, it is not enforced when the program runs, and it is genuinely useful in larger scripts.

It is Module 11 — Functions, because it is most valuable at the boundaries where one piece of code hands a value to another. Introducing it here, before there are any such boundaries, would be notation without a purpose.

8. Predict, Run, Observe

Predict every line, including types.

value = 10
print(value)
print(type(value))

value = "ten"
print(value)
print(type(value))

value = None
print(type(value))

10
<class 'int'>
ten
<class 'str'>
<class 'NoneType'>

Then answer for yourself: at the last line, could a reader who joined at that point tell what value had been earlier? That question is the whole argument of §5.

9. Exercise

Exercise 1 — demonstrate it. Write a file where one name refers in turn to a whole number, a decimal, some text, and None, printing the type each time. Confirm Python never objects.

Exercise 2 — say it correctly. A colleague says "Python variables don't have types". Correct them in one sentence without saying they are entirely wrong — because the thing they are pointing at is real.

Exercise 3 — judge two versions. Which of these would you accept in review, and why?

# version A
seed_text = "4210"
seed = int(seed_text)

# version B
seed = "4210"
seed = int(seed)

Both work. Give the reason in terms of what a reader of line 40 can rely on.

Exercise 4 — the maintenance question. A script has a name result that refers to text in one place, a number in another and None in a third. You have been asked to add a feature. Name two specific things you now have to do before you can safely write a single line.

10. Summary

• Values have types; names do not. A name is a label, and it can be pointed at a value of any type.
• This property is called dynamic typing — and "Python has no types" is the wrong way to describe it. Python's types are real and enforced when values are used.
• The difference from C or SystemVerilog is the absence of a declaration, not the absence of type checking.
• It makes conversion read naturally, which is why Chapter 2.11 needed no casting syntax.
• Permitted is not desirable. A name that changes meaning partway through costs every future reader a trace through the file.
• Give a converted value its own name — seed_text and seed. One extra name; a reader who can trust what they see.
• Optional type annotations exist and are deferred to Module 11, where there are boundaries worth annotating.

Two chapters left. The next one takes the name/value model one step further and asks a question that has been lurking since Chapter 2.3: can a value itself ever be changed?