Study material generated by AI from this openly licensed book (CC BY-NC 3.0). Not affiliated with or endorsed by the publisher.
Think Python, 2nd Edition, by Allen B. Downey, Green Tea Press, licensed under CC BY-NC 3.0. Read the original free
Chapter 20 · pp. 215–222
Debugging means finding and fixing the mistakes in a program. Different mistakes need different tools, so the first job is to work out what kind of error you have. This chapter covers the three kinds of error and practical techniques for tracking each one down.
def line. (p. 215)The first debugging step is to decide which kind you have. If Python refuses to start, suspect syntax. If it crashes with a message, it is a runtime error. If it finishes with a wrong answer, it is semantic. Knowing this tells you where to look. Some tools, such as print statements, help in more than one case. (p. 215)
Where the message points. A common wrong belief is that a syntax error message marks the exact faulty line. It actually shows where Python noticed the problem, and the real mistake is often earlier, frequently on the line before. For example, an unclosed bracket on line 3 may only cause an error on line 4, because Python treats line 4 as a continuation of line 3. If you add code a little at a time, check the last line you added first. (pp. 215–216)
Common slips. Most syntax errors come from a short list:
for, while, if, or def header.(, {, or [.= where == is needed in a condition.(p. 216)
When your changes seem to do nothing. Maybe you and Python are not looking at the same code. Test this by putting a deliberate syntax error at the top of the file and running it. If Python does not complain, it is running some other version. Likely causes:
If you are still stuck, start from a working 'Hello, World!' program and add the original code back piece by piece. (pp. 216–217)
A program that does nothing. This often happens when a file defines functions but never calls one. Add a call, and make sure execution actually reaches it. (p. 217)
A program that hangs. A hang usually means an infinite loop or infinite recursion. To check a suspect loop, print a message just before it ('entering the loop') and another just after ('exiting the loop'). If you see only the first message, the loop never ends. (pp. 217–218)
while x > 0 and y < 0, you would print x, y, and the result of x > 0 and y < 0. On the last pass the condition should be False. If it never is, the printed values show why x or y is not changing as you expected. (p. 218)Flow of execution. If you are unsure which functions run, or in what order, print 'entering function foo' at the start of each function. The output is a trace of the calls. It also shows when a function is defined but never called. (pp. 217–218)
When a runtime error occurs, Python prints the exception name, the line where it happened, and a traceback. The traceback lists the function running now, then the function that called it, then that function's caller, and so on, with a line number for each. Read it first, because it tells you where to look. (pp. 218–219)
Each common exception suggests a typical cause (p. 219):
'Name' and 'name' are different keys.NoneType, the object itself is None. Two common reasons are a function with no return statement (it returns None) and using the result of a method like sort, which returns None.The Python debugger, pdb, can also show the program's state just before an exception. (p. 219)
Print statements can bury you in output. You have two options (pp. 219–220):
Finding the smallest failing case often reveals the bug, because a program that works in one situation but not another gives you a clue. (p. 220)
Semantic errors are the hardest, because the interpreter gives no hints and only you know what the program should do. You need a hypothesis about what the program is really doing. Ask yourself three questions (p. 220):
Often the problem is a wrong mental model of how the code works, not the code itself. The cure is to split the program into components, such as functions, and test each one independently until you find where reality differs from your expectation. If you build and test as you go, only a small amount of new, unverified code remains when something breaks. (pp. 220–221)
A long expression is hard to debug. Break it into steps using temporary variables. The names document what each part means, and you can print or check the type of each intermediate value. (p. 221)
The order of evaluation can also surprise you. To write , you might type y = x / 2 * math.pi. But multiplication and division have the same precedence and run left to right, so this computes . The fix is explicit parentheses: y = x / (2 * math.pi). Whenever you are unsure of the order, add parentheses. This makes the code correct and easier for others to read. (p. 221)
The same trick helps with return values. Instead of returning a complex expression directly, store it in a temporary variable such as count, print it, and then return it. (pp. 221–222)
y = x / 2 * math.pi not compute , and how do you fix it?