Reading Python Output and Error Messages

Learn to separate ordinary program output from a Python error report. Read a short traceback from its final line, identify the relevant source location, and use the message to choose a small correction.

Running a program gives us something to inspect. Sometimes Python produces the output we expected. At other times, it stops and explains what prevented it from continuing.

Learning to read both results is part of programming. We do not need to understand every detail immediately. We need to separate ordinary output from an error report and find the part that helps us decide what to inspect next.

Read Ordinary Output

Consider this program:

It produces two lines:

starting
5.0

The first print() call produces the first line. The second call divides 10 by 2 and prints the result on the next line. The order of the output follows the order in which Python runs the two calls.

Output is easier to interpret when each line identifies what it contains:

distance: 12
time: 3
speed: 4.0

The labels are part of the output. Python does not add them automatically. They make it possible to tell which value came from which calculation.

Compare Expected and Actual Output

Before running a small program, it helps to predict what it will print. The prediction is the expected output. What the program actually prints is the actual output.

Suppose we expect this program to print total: 12:

The actual output is:

total: 7

Python ran the written instruction correctly, but the instruction used addition where the intended calculation required multiplication. The difference between the expected and actual output directs our attention to price + quantity.

Output therefore provides evidence about what the program did. It does not by itself prove that the program did what we intended.

When Python Cannot Continue

Python stops when it reaches an instruction that it cannot run. For example, this program tries to use score before assigning a value to that name:

The first line is printed. Python then stops at print(score), so the final print() call is never reached.

checking score
Traceback (most recent call last):
  File "report.py", line 2, in <module>
    print(score)
          ^^^^^
NameError: name 'score' is not defined

The normal output appears before the traceback because the first instruction finished successfully. The traceback begins when Python reports the failure.

The browser runner can show more traceback locations than the short report.py example above. Those extra lines describe the code used by the browser to start Python and run the lesson. Begin with the final error line, then look upward for the location marked <lesson>; that location refers to the code in the editor.

An execution environment may also display status messages while it starts Python or loads a package. For example, it may report that NumPy is loading. These messages describe the environment rather than output produced by a print() call in the program.

Read a Traceback from the End

A traceback records where Python was running when an error occurred. A larger program can include several locations, but this first example contains one:

Traceback (most recent call last):
  File "report.py", line 2, in <module>
    print(score)
          ^^^^^
NameError: name 'score' is not defined

We can read it from the final line upward:

1. NameError names the category of error.
2. name 'score' is not defined identifies the missing name.
3. print(score) shows the instruction Python was trying to run.
4. line 2 tells us where that instruction appears in report.py.

A caret is the ^ symbol. The row of carets under score points more precisely to the part of the instruction involved in the error. Some Python versions and execution environments omit these symbols or show additional traceback locations. The error category, message, and relevant source location still serve the same purpose.

For a short traceback, four questions are usually enough:

1. Which line was Python running?
2. What is the error category?
3. Which name, value, or operation does the message mention?
4. What small correction would address that message?

This method is more reliable than changing unrelated lines until the program happens to run.

Error Categories Describe Different Problems

The name at the end of a traceback identifies the kind of problem Python encountered. These examples use only ideas already introduced in this chapter:

The category narrows the search, but it does not repair the program for us. The message and source line provide the details needed to understand this particular case.

An Error Does Not Erase Earlier Work

An error stops the current run at the failing instruction. Instructions that finished earlier in the run may already have printed output or performed other work. Instructions after the failing line do not run.

This order matters when reading a mixed result:

begin
Traceback (most recent call last):
  File "calculation.py", line 2, in <module>
    print(8 / 0)
ZeroDivisionError: division by zero

The word begin is ordinary output. Everything from Traceback onward belongs to the error report.

NameError: name 'loss' is not defined

loading
Traceback (most recent call last):
  File "example.py", line 2, in <module>
    print(total)
NameError: name 'total' is not defined

Use the Report to Choose the Next Change

Reading a result follows a repeatable sequence: separate normal output from the traceback, find the final error category and message, locate the relevant source line, and identify one correction that addresses the reported problem.

The next lesson turns that reading method into a working loop. We will predict a result, edit one part of a program, run it again, and compare the new output with what we expected.