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:

age_value_path.py

One line is returned for each input() call, in order.

OutputRun with button or Ctrl/Cmd+Enter
Run the code to see output.
Ready to edit. Press Run when you want evidence.

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 integer 1?

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.

unit03_practice.py

One line is returned for each input() call, in order.

OutputRun with button or Ctrl/Cmd+Enter
Run the code to see output.
Ready to edit. Press Run when you want evidence.

This runs in an isolated Python worker in your browser. Your edits stay in this browser until you reset them.