Debugging in Python, part 3: Fixing a "simple" bug
MP 140: How can we take a systematic approach to a "simple" bug?
Note: This post is part of an ongoing series about debugging in Python. The posts in this series will only be available to paid subscribers for the first 6 weeks. After that they will be available to everyone. Thank you to everyone who supports my ongoing work on Mostly Python.
The goal for this series is that when you see a bug, you'll be able to think to yourself:
I've seen this kind of error before! I know how to read the traceback, and I have a good idea how to start fixing it.
That's a lofty goal, and it's not possible to cover all kinds of errors in one series. If the error you're facing is one you haven't seen before, the goal is to have a reliable, systematic approach that you can fall back on. In this post, we'll go through the process of resolving a small bug in a single-file project. Starting with a small bug will let us focus on the most essential parts of error messages, and the overall debugging process.
A note about "simple"
It's a good idea to be careful about the word "simple" in general, but that's especially true when talking about bugs and debugging. A bug that's simple for one person to reason through might be quite difficult for someone else. Here I mean we're looking at a single issue in a single-file project. There's no deeper root cause; once we fix the bug, the issue will have gone away.
A working program
If we're going to practice debugging, we need to start with a file that doesn't have any bugs. Here's a program that simulates a two-player game using dice. Each player rolls once, and whoever gets the higher number wins:
This post is only available to paid subscribers at the moment. It will be available to everyone 6 weeks after posting. If you'd like to continue reading now, please support my work by signing up for a paid subscription.
