Unit 03 · lesson
Follow the Value
Core path: 30 minutes
Most beginner type errors are not really about memorizing str, int, or float.
They happen because the student loses track of a value as it moves through the program.
So this lesson does something less flashy and more useful: we follow one value from the keyboard all the way to the final output.
One input, several identities
Consider:
age_text = input("Age: ")
age = int(age_text)
next_year_age = age + 1
print(next_year_age)
Suppose the user types:
16
What exists after the first line?
Not the integer 16.
input() returns text, so Python receives the string:
"16"
The value path is:
keyboard characters
↓
"16" string
↓ int(...)
16 integer
↓ + 1
17 integer
↓ print(...)
17 displayed output
Those are not four unrelated facts. They are one chain.
Run that same chain and use the output to identify the exact line where the representation changes:
One line is returned for each input() call, in order.
Run the code to see output.
Follow one value through input, conversion, calculation, and output. Change the input and explain exactly when its type changes.
Why the conversion belongs where it does
You could write:
age = input("Age: ")
and leave it as text for a while.
That is perfectly valid if all you plan to do is print the age back to the user.
The problem appears when the program needs numeric behavior:
next_year_age = age + 1
Now Python has to answer a specific question:
What does it mean to add the string
"16"and the integer1?
There is no valid operation for that combination.
So conversion is not ceremony. It changes what operations are available.
Similar-looking values are not the same value
Run or reason through these:
print("5" + "2")
print(5 + 2)
print(float("5") + 2)
Expected results:
52
7
7.0
The screen shows digits in every case, but the program is working with different types underneath.
That hidden type is part of the system state.
Trace a failure before repairing it
Look at:
hours = input("Hours per week: ")
yearly = hours * 52
print(yearly)
A lot of students expect a numeric estimate.
But multiplying a string by an integer has a defined meaning in Python: repeat the string.
If the user enters 8, the program does not calculate 416. It repeats the text "8" fifty-two times.
That can be more dangerous than a crash because the program runs.
Valid syntax does not guarantee valid logic.
Repair it:
hours = float(input("Hours per week: "))
yearly = hours * 52
Now the operation matches the meaning of the data.
A value can change without the name changing
Consider:
score = 10
score = score + 5
Read the second line slowly.
Python evaluates the right side first:
score currently refers to 10
↓
10 + 5
↓
15
Then the name score is assigned the new result.
After the line runs, score refers to 15.
The name stayed the same. The value associated with it changed.
That is why score = score + 5 is not a mathematical equation. It is an assignment operation.
The debugging question gets better
In Week 2 the useful question was:
Where is my terminal?
This week the useful question is:
What value is this name referring to right now, and what type is that value?
Use:
print(variable)
print(type(variable))
when you need evidence.
Later we will use a debugger to inspect state without adding temporary print statements everywhere. For now, printing the value is completely legitimate.
Trace your own profile program
Choose one numeric input from Lesson 4.
Create a trace like this using the real values from one run:
user types:
input() returns:
type before conversion:
conversion:
type after conversion:
calculation using the value:
new value produced:
final output line:
Then choose one text input and explain why it does not need numeric conversion.
Finally, answer this:
At what exact point would the program fail or behave incorrectly if the conversion were removed?
That answer is more useful than saying "Python needs types."
You are starting to see the program as moving state instead of a page full of code. That mental shift matters.
Reader workbench
Trace input through conversion and state
This is the Unit's one-file practice surface. Read the code, predict one result, run it, then change a value, input, condition, or boundary and explain why the evidence changed. Multi-file projects, Git, terminals, packages, and live services still belong in the full development workspace.
One line is returned for each input() call, in order.
Run the code to see output.
This runs in an isolated Python worker in your browser. Your edits stay in this browser until you reset them.