1. Introduction
Debugging is the process of finding and removing bugs or defects in a program. To help my daughter with her first Python class, I looked around for information on debugging that I could share with her. I wanted a simple guide with everything in one place and suggestions for how to go about the process of debugging. Initially, my research focused on gathering examples of common issues, but I knew something more was needed. After all, what happens if there is no example of the bug that youre experiencing?
I knew I needed to provide a debugging foundation. Not just how to use debugging tools, but when to take action and why. With that goal in mind, Chapters 1 through 6 build a debugging arsenal, so youre ready to tackle the examples in Chapter 7. Each example begins with References to the related topics covered in earlier chapters. So theoretically, you could jump right into the examples in Chapter 7.
This book includes an extensive and detailed Table of Contents. I also made a point to cross-reference topics so you can easily locate whatever youre interested in from any point in the material. This approach means you can pick up the book at any time and quickly jump back in where you left off. Or if you prefer, you can hop around from topic to topic with as much detail as you want.
Hopefully, after reading this book, you wont feel like this man who posted a plea for help on a chat board. His frustration shows through in his comment, For the love of God, how is this done? Instead, youll know exactly how its done and have fun doing it!
1.1 Overview
How you may ask, are we going to build your debugging arsenal? Lets begin with these topics.
How to use the debug environment.
The Python Error Codes and specific examples of how they happen.
Step-by-step instructions on the process of debugging code.
Finding the information you need to modify your program : help on Syntax, Functions, Classes, and more.
The goal of debugging is a working program, and debugging is just part of the process of writing code. When I realize I have a bug, Ill experiment and try a few things to find a clue where the issue is. Youll see this process in the examples in Chapter 7, where I use different approaches from my debugging toolbox to isolate an issue. You might take a different approach to the sample problem, and there is no wrong approach. The idea is to try a few things and see what works.
In this book, I demonstrate Python using the open-source Anaconda Data Science Distribution that includes Python version 3.7. Spyder, the Scientific Python Development Environment, comes with Anaconda. You may notice slight differences in screenshots, depending on whether I am using Spyder on my Windows or Mac computer.
1.2 What This Book is About
My intent in writing this book was not to provide a guide to Python Programming. Instead, this book is specifically about debugging Python with Anacondas Spyder application. The concepts around Python debugging apply equally to other environments, but the screens and debugging tools may vary slightly.
You may wonder why Ive included Python Basics in Chapter 3. I found it difficult to explain an IndexError without first explaining data structures and their indexes. Similarly, a Dictionary KeyError doesnt mean much without an understanding of a Dictionary. Syntax errors are fairly obvious in Spyder, but it doesnt hurt to have a brief explanation of the syntax the parser expects.
Finally, Chapter 6 demonstrates how to view values, types, and the length of objects. Since the syntax varies by the type of object, I wanted to provide a reference with the exact syntax for each object type.
1.3 Whats Next?
The next chapter walks you through installing Anaconda and the basic Spyder environment. Well also look at an overall plan for debugging code.
2. Debugging Overview
In this Chapter we discuss
Plan for Debugging
Start Small
Keep Multiple Versions of Your Code
Intended Outcome
Test Data Files
Plan for Tomorrow
Experiment
Divide and Conquer
The Debugging Environment
Python
Anaconda & Spyder
Help
Whats Next?
Writing code begins with your vision of what the program should do. You write code, see what happens, and make changes along the way. When the code doesnt do what you want, debugging helps you zero in on whats happening while the code runs. In essence, you can pause program execution and freeze your program at that point in time, looking at variable and object values at that moment.
This Chapter outlines a few suggestions to approach programming and debugging. The Examples in Chapter 7 follow a similar methodology.
Intended Outcome : What I wanted the program to do.
Actual Result : What the program did.
Incorrect Code : A look at the code before any changes.
Debugging Experiment : What I suspect is wrong with the program, and the steps I tried to debug what the program is doing.
How to Resolve the Issue : A brief description of the change to the code to achieve my Intended Outcome.
Correct Code : The finished code that works as I intended.
2.1 Plan for Debugging
Programming is not my primary job. Instead, programming is a tool I use for data mining or organizing projects. A day in my programming life includes lots of interruptions. It may be weeks or months before I pick up a project and continue coding. For this reason, Ive adopted a few suggestions from programming friends to make my life easier.
Work on small chunks of code, test, and then move on to the next piece.
Keep multiple backup versions of your files.
Have a clear idea of what you want your program to do.
Use small data file samples that you know have clean data to develop your code. When youve tested your code and are confident there are no bugs, use live data connections or real data files.
Keep notes of where you stopped programming and the next steps.
Start Small
Write small chunks of code. Test and validate that piece of code, then move on. This Correct Code is also a good baseline for backups.
Keep Multiple Versions of Your Code
Keep multiple backup versions of your files. My backup files often include the date and time in the filename. That way, if I really mess up the code, I can easily go back to the Correct Code that worked earlier today or last month.
Intended Outcome
While Im not suggesting you have a vision statement for your program, it doesnt hurt to have an Intended Outcome of what youre trying to accomplish. This synopsis is beneficial in several ways:
Pair programming, or asking for another opinion.
When you check-in your code to a source control program.
During peer review.
In a Sprint Review, where you demonstrate your program to others.
In case you reach out to another programmer for assistance, share as much information as possible.
The incorrect code. If you have the last working version of your code, that might also be helpful.