Python Debugging

Debugging in any programming language typically involves two types of errors: syntax or logical. Syntax errors are those where the programming language commands are not interpreted by the compiler or interpreter because of a problem with how the program is written. These types of errors cause the program to either stop at the offending code or give a warning or error when the program execution is attempted. Once all of the syntax errors are discovered and corrected, logical errors still allow the program to run to completion but give incorrect results. Logical errors can be corrected by testing multiple conditions to check the correct operations or output of the program. Debugging in Python can either involve print statements or a more sophisticated debugger interface such as Spyder or ipdb.

Generative AI Learning

Debugging is the skill that makes AI-generated code safe to use, because generated code fails in exactly the two ways this page names: loudly (syntax/runtime errors) and silently (logical errors). Use these prompts to train both.

"Quiz me with 5 questions, one at a time, on Python debugging: how to read a traceback (start at the bottom line - the error type and message - then walk up the call stack to find MY line), the difference between a syntax error, a runtime exception, and a logical error, what NameError, TypeError, and IndexError each typically mean, where a print statement goes to bisect a failure, and why 'the program ran without errors' does not mean the answer is right. Grade my answers and list my misconceptions."
"Take this short working script {paste a working script of yours, ~20-40 lines} and return a version with THREE planted bugs: one that raises an exception, one that changes the numerical result silently, and one that only appears for certain inputs. Do not tell me where they are. I will find all three by reading, tracing, and testing - I will report each bug, its category, and my fix, and you grade my debugging process, not just the answers."

Tip: Rubber-duck the AI: before asking it to fix anything, explain your bug to it line by line as if it knows nothing - state what each line should do and what you observe instead. Most bugs die during the explanation. When you do paste a traceback, ask for the diagnosis and the reasoning, not just a patched file: you are training yourself, and an AI fix you cannot explain is a bug you will re-create next week.

What to Turn In

Submit a short report (PDF, 1-2 pages) that curates your results into a demonstration of what you learned. You may use Generative AI to help write the report, but the debugging must be demonstrably yours. Answer these questions:

  1. Keep a bug journal for this class's work: for three real bugs you hit (yours or planted), record the symptom, the traceback's bottom line in your own words, the root cause, and the fix.
  2. From the three-planted-bugs hunt: report each bug, its category (loud / silent / input-dependent), how you found it, and the test that proves your fix - did you find all three before asking for the reveal?
  3. Show one example of the rubber-duck technique: the explanation you wrote and the moment (which line) where the bug became obvious.
  4. From the quiz prompt: one question you missed and the corrected answer.

Course Information

Excel and VBA

Python

MATLAB

MathCAD

Related Courses

Admin