Trace Values and Assumptions

Inspect values, types, lengths, keys, and intermediate state just before a failure, then follow the first unsuitable value or broken assumption backward.

The traceback located a failed addition inside mean_from_records. Its message says that one operand is a float and the other is a string. Now the task is to find which input produced that state and when it first became unsuitable.

The intended rule is precise: a record has "sensor" and "reading" keys; an available reading is numerical; None means unavailable and is skipped.

Inspect State Immediately before the Operation

Temporary output can expose the values used by each iteration:

These lines inspect several possible assumptions without changing the calculation:

record shows the current input value;
sorted(record) shows the available keys;
reading and type(reading) show the operand about to reach addition;
total and count show intermediate state carried from earlier iterations.

The input length can also be useful:

print("record count:", len(records))

Length matters when a loop visits too few or too many items. Available keys matter when a lookup fails. Values and types matter when an operation receives the wrong kind of data. Print the evidence connected to the failed assumption, not every name in the program.

Q1. Choose evidence for the failed addition

Which temporary output most directly checks the two operands just before total = total + reading?

Choose one

print(total, type(total), reading, type(reading))

print(len(records)) only

print("debugging")

Select one choice, then check.

HintRead the expression first

The addition uses total and reading.

SolutionInspect both operands

Printing each operand beside its type tests the exact assumption that the two current values support numerical addition.

Find the First Bad State

Run the instrumented function and compare each iteration with the intended rule:

Iteration	Sensor	Reading and type	State before update	Result
1	north	`18.0`, `float`	`total=0`, `count=0`	update to `18.0`, `1`
2	east	`None`, `NoneType`	`total=18.0`, `count=1`	skip; state remains `18.0`, `1`
3	west	`"24.0"`, `str`	`total=18.0`, `count=1`	addition fails

The first two iterations keep the rule. The third record has the expected keys, so dictionary lookup succeeds. Its reading is the first unsuitable state: text reaches a calculation that expects a number or None.

The traceback appears one line later, when addition tries to use that state. This distinction prevents a common mistake: treating the last successful state as the problem merely because it appears near the failure.

Trace the unsuitable value backward:

west input record
    → record["reading"]
    → local name reading
    → total + reading
    → TypeError

The trace identifies a broken input assumption. It does not yet choose a policy. The program might reject invalid text, convert expected numeric text, or repair the source that created the record. Later lessons will make those boundary decisions explicit.

Q2. Identify the first unsuitable state

At which point does this run first violate the rule “each reading is numerical or None”?

Choose one

when the north reading is 18.0

when the east reading is None and is skipped

when the west lookup produces the string "24.0"

Select one choice, then check.

HintSeparate absence from invalid text

The function deliberately handles None by skipping it.

SolutionThe west lookup creates the first bad state

The north float is valid and the east None follows the established absence path. The west record first breaks the rule when its "reading" lookup returns a string.

Keep Diagnostics Temporary and Focused

Diagnostic output is part of an investigation, not the final report. Once the cause is understood and a repair is verified, remove temporary lines such as:

Leaving them in would mix internal evidence with the report a reader expects. If the same assumption deserves a permanent executable check, state it through validation or an assertion in the appropriate later lesson; do not leave a large collection of prints as accidental program behavior.

One useful diagnostic should make a hypothesis testable. This small inspection loop isolates the input without running the failing calculation:

Q3. Expose every arriving reading type

Complete the diagnostic line so the program displays each sensor, its reading, and the reading's type. Do not change the input values.

Editable Python

HintInspect without repairing

Add type(reading) as the third displayed value. Keep the west reading as text so the evidence remains visible.

SolutionDisplay the current value and type

Inspect the state immediately before the failed operation, then trace the first unsuitable value backward to its source. Values, types, lengths, keys, and intermediate state answer different hypotheses. Remove temporary diagnostics after verification. Some defects produce no traceback at all, so the next lesson compares a plausible answer with a hand-worked case.