Checkpoint: Read Before You Run

You have watched Python run a file from the top line down, and you have moved one value at a time to see the output follow. This checkpoint asks the harder version of that skill: can you say what a short program prints before you press Run?

Every question below uses the same scene, a market stall packing jam into crates, so the only thing changing between them is the Python.

The rules these questions test

Assignment is not a promise to keep two names in step. When Python reaches crate_note = f"packed {jars_packed} jars" it evaluates the right side once, builds one finished string, and binds that string to crate_note. Rebinding jars_packed afterwards changes where jars_packed points and nothing else.

Two shorter rules ride along with it. The f before the opening quote is the whole reason {jars_packed} turns into a number; drop that prefix and the braces stay on screen as plain characters. And print does two separate things: it shows a value, then hands back None, so a name bound to print(...) holds None rather than the sentence you just read.

jars_packed = 12
crate_note = f"packed {jars_packed} jars"
jars_packed = 18
print(crate_note)

Line 2 read the value 12 and froze it into the text, so line 4 prints packed 12 jars while jars_packed already holds 18.

Each question tests one of these rules. Track the value stored by an assignment separately from the text shown by a print call. When you can explain both, the output follows from the code rather than from a guess about what the author intended.

Read the last line of a snippet first, then walk upward to find where each name got the value it is holding.

Three questions from the jam stall

Take each snippet one line at a time, in the order the interpreter takes it, and commit to an answer before you check.

The stall starts the morning with 120 empty jars. After these four lines run, what does the last one show?

jars_packed = 40
jars_left = 120 - jars_packed
jars_packed = 55
print(jars_left)

80

65

55

Both print calls describe crate C12. What does the second of them put on screen?

crate_id = "C12"
jars = 3
print(f"crate {crate_id} holds {jars} jars")
print("crate {crate_id} holds {jars} jars")

crate C12 holds 3 jars

crate {crate_id} holds {jars} jars

a NameError, because the braces name nothing

Sealing a crate should leave a record. What does this snippet put on screen?

receipt = print("crate C12 sealed")
print(receipt)

crate C12 sealed, then crate C12 sealed

crate C12 sealed, then None

crate C12 sealed, and nothing after it

Check it yourself

Use the console below to test your predictions. If an answer differs, find the first line where your expected state differs from the program's state, then trace forward from there.

Running all three jam-stall cases and labeling each result

Python 3 · Edit the code and run it without leaving the lesson.

Language

Run code to see results here.

Program input (stdin, optional)

The case 1 line prints 80, case 2b keeps its braces, and case 3b prints None. Now change jars_packed = 55 to jars_packed = 200 and run again: case 1 will not budge, because line 3 finished its subtraction long before that edit.

Where the answers slip

Reading jars_left = 120 - jars_packed as a live formula rather than one subtraction that already happened.
Typing the braces but dropping the f, which prints {jars} instead of 3 and raises nothing to warn you.
Storing whatever print(...) returns, which is always None, and expecting the text to come back.

What's next

Section 2 stops treating every value as interchangeable and starts asking what each one actually is.

You will name the type behind 120, "C12", and True, and find out why 120 and "120" refuse to mix.
You will run +, //, and % on jar counts and watch integer division quietly drop a remainder.
You will slice and format text so a crate label gets built from parts instead of retyped by hand.