When Python Refuses to Run: Reading the Error

Part I · Module 1 · Chapter 1.11 · When Python Refuses to Run: Reading the Error

1. An Error Is Information

When Python cannot do something, it stops and prints a message. That message is not a complaint — it is a report, and it contains almost everything you need.

Every error tells you at least three things:

• Where — the file and the line number.
• What kind of problem it is — a name, like SyntaxError.
• A description of the specific problem.

The reason beginners struggle is not that the messages are unclear. It is that they are read in the wrong order, or not read at all.

2. The Method

Four steps, every time:

1. Read the last line. It names the kind of error and describes it.
2. Find the line number. Python tells you where it gave up.
3. Look at that line, and read the description. Modern Python is good at pointing at the real cause — an unclosed bracket is reported at the bracket, not further down. Where the description names a specific character, that character is what to look for.
4. Change one thing, and run again. Do not change three things at once; you will not know which one mattered.

3. SyntaxError — the Shape Is Wrong

You caused this in Chapter 1.4. Here it is properly.

print("Compile")
print("Simulate)

  File "hello.py", line 2
    print("Simulate)
          ^
SyntaxError: unterminated string literal (detected at line 2)

Step 1 — last line. SyntaxError: unterminated string literal. "String literal" is Python's name for a piece of text in quotes. "Unterminated" means it never ended.

Step 2 — where. line 2.

Step 3 — look. Line 2 opens a quote before Simulate and never closes it. Python read to the end of the line still waiting.

Step 4 — fix and rerun.

print("Compile")
print("Simulate")

Compile
Simulate

Notice what happened before the fix: neither line printed, not even the correct first one. This is a shape problem, caught when the file was compiled, so nothing ran at all — exactly as Chapter 1.4 §4 predicted.

That caret ^ under the line is Python pointing at where it noticed the problem. It marks where Python gave up, which is not always where you made the mistake, but it is always close.

4. NameError — Python Does Not Know That Word

print("Compile")
prnt("Simulate")

Compile
Traceback (most recent call last):
  File "hello.py", line 2, in <module>
    prnt("Simulate")
    ^^^^
NameError: name 'prnt' is not defined. Did you mean: 'print'?

Step 1 — last line. NameError: name 'prnt' is not defined. Python does not know anything called prnt.

Step 2 — where. line 2.

Step 3 — look. prnt is a typo for print.

Step 4 — fix and rerun. Correct the spelling and both lines print.

Two things are different from §3, and both are worth noticing.

Compile printed first. The shape of the file was fine, so it compiled and started running. Line 1 worked. The failure only happened when line 2 was reached. That is the difference between the two kinds of failure from Chapter 1.4 — and it is why some output then a stop tells you something quite different from no output at all.

The word Traceback. That appears on run-time failures and is the list of where Python was when it stopped. In a file this simple it is one line. You do not need it yet; the last line is still the one that matters.

5. IndentationError — a Line Is Pushed In

print("Compile")
 print("Simulate")

  File "hello.py", line 2
    print("Simulate")
IndentationError: unexpected indent

Step 1 — last line. IndentationError: unexpected indent. A line is indented and Python has no reason for it to be.

Step 2 — where. line 2.

Step 3 — look. There is one space before print.

Step 4 — fix and rerun. Delete the space.

And again: no output at all, because indentation is part of the shape. Chapter 1.10 covers this rule in full.

6. The Three Together

The right-hand column is the diagnostic. Before reading anything else, ask: did any of my output appear?

• None at all → a shape problem. Look at the reported line and the one before it.
• Some, then a stop → the shape was fine; a specific line asked for something impossible, and everything above it already worked.

7. What This Chapter Is Not About

Python lets you catch errors and decide what to do about them rather than stopping. That is a real and important tool, and it is Module 14 — Errors and Exception Handling.

It is deliberately not here. Catching an error before you can reliably read one is the wrong order: you end up hiding problems you have not learned to understand. For the whole of Modules 1 to 13, when Python stops and tells you something, the right response is to read it and fix the cause.

8. Predict, Run, Observe

For each, predict two things: whether any output appears first, and which error name you expect.

(a)

print("one")
print("two"
print("three")

(b)

print("one")
Print("two")

(c)

print("one")
   print("two")

Run each and check both predictions. If you got the did output appear half right every time, you have the model from Chapter 1.4 and you will save hours with it.

(Answers: (a) no output, and the message is SyntaxError: '(' was never closed, reported at line 2 — Python names the exact character it is still waiting for. (b) one prints, then NameError — Python is case-sensitive and Print does not exist. (c) no output, IndentationError.)

9. Exercise

Exercise 1 — the four steps, out loud. Take any error you produced above and narrate the four steps of §2 for it. The habit is what you are building, not the answer.

Exercise 2 — two different SyntaxErrors. Produce both of these and compare the last line of each: a missing closing quote, and a missing closing bracket. Python gives them different descriptions. Write down both, and say in one sentence what each description tells you to go looking for.

Exercise 3 — break it four ways. Starting from a correct three-line file, produce in turn: a SyntaxError, an IndentationError, a NameError, and a file that runs but prints the wrong thing. Which of the four did Python not warn you about, and why is that the most dangerous one?

Exercise 4 — fix from the message alone. Write a five-line file, deliberately break it in one place, close it, and come back after a few minutes. Fix it using only the error message, without hunting through the file. That is the real skill this chapter exists for.

10. Summary

• An error is a report, not a failure. File, line number, kind of problem, description.
• Read the last line first — it names the problem. Then get the line number.
• Four steps: read the last line, find the line number, look at that line and the one above, change one thing and rerun.
• SyntaxError and IndentationError are shape problems — caught at compile time, so nothing runs, not even correct lines above them.
• NameError is a run-time problem — the shape was fine, so earlier lines already ran.
• Did any output appear? That one question sorts the two kinds apart before you read anything else.
• The reported line is where Python gave up, which for unclosed brackets is often the line after the mistake.
• Catching errors is Module 14. For now, read and fix.

That completes Module 1. You can write a Python file, run it, display things, annotate it, keep its layout legal, and recover from the three mistakes you are most likely to make. Everything from here is about what you put inside those lines — and the first thing to put in them is data.

Module 2 — Variables and Data Types begins with the idea the whole language is built on: giving a value a name so you can use it again.