Goal

You’ll practice debugging and reviewing existing Python code, applying diagnostic thinking from across this entire course to spot problems in code you didn’t write yourself.

Learn

Debugging and reviewing code is a genuinely different skill from writing new code — it requires actively looking for specific known problem patterns, not just reading code and assuming it’s correct because it superficially looks reasonable. A structured review checklist, pulling together this whole course:

• Type handling (Part 1.1, 1.4): Are values being used with operations appropriate to their actual type? Is input() output being converted before arithmetic?
• Mutable defaults (Part 3.2): Does any function use a mutable object (list, dict) as a default argument?
• Exception handling (Part 3.4): Are exceptions caught with specific types, not bare except: that could hide genuine bugs?
• File safety (Part 4.4): Are files opened using with, guaranteeing proper closure even if an error occurs?
• Class design (Part 4.1, 4.3): Does self appear correctly in every method? Does printing an object show something genuinely useful via __str__?

This kind of review reveals that code can run without crashing and still contain genuine, real problems invisible to a quick read-through — a mutable default argument bug, for example, often doesn’t surface until the function has been called multiple times in a way that reveals the shared, accumulating state, not on the very first call.

Decision Task

You’re reviewing a function def add_log(entry, logs=[]): that appends entry to logs and returns it. Before reading on: what specific bug does this contain, and why might it pass initial testing successfully despite the bug being present?

Show Answer

This has the mutable default argument bug from Part 3.2 — logs=[] is created once at function definition, not fresh each call, so multiple calls without explicitly providing their own logs argument would share and accumulate into the same list. It might pass an initial single test successfully (one call looks correct on its own), since the bug only becomes visible once the function is called multiple times in a way that reveals the unexpected accumulated shared state.

Common Mistake

Reviewing code purely by checking “does it run without crashing” rather than deliberately checking for the specific known problem patterns covered throughout this course. As this lesson demonstrates, code can run successfully on a first, simple test while still containing a genuine bug that only reveals itself under slightly different conditions — deliberate, structured review catches this; casual reading often doesn’t.

Practice Questions

1. A reviewed function has except: with no specific exception type. What problem does this represent, from Part 3.4?

Show Answer

A bare except: silently catches every possible error identically, including genuine bugs unrelated to the expected error case, making real problems harder to find since they’re hidden behind the same generic handling.

2. A reviewed class has a method defined without self as its first parameter. What will happen when that method is actually called normally?

Show Answer

It will raise an error when called, since Python automatically passes the calling object as the first argument, and a method missing self in its definition can’t correctly receive it.

3. A reviewed program manually calls open() and close() around file operations that could raise an exception in between. What real risk does this carry, from Part 4.4?

Show Answer

If an exception occurs between open() and close(), the close() call gets skipped entirely, potentially leaving the file improperly closed and causing data loss or file-locking issues.

4. True or False: code that runs successfully without crashing during a quick test is sufficient evidence that it’s free of genuine bugs.

Show Answer

False — this is the core lesson here; some real bugs (like mutable default arguments) only reveal themselves under specific conditions not covered by a simple initial test.

5. List the five review checklist categories from this lesson, in your own words.

Show Answer

Type handling, mutable default arguments, exception handling specificity, file safety (using with), and class design correctness (self, __str__).

Try It Yourself

Using this lesson’s checklist, review a piece of your own Python code from earlier in this course (or one you’ve written elsewhere) and see if you can spot at least one place where the code could be made more robust, even if it currently works correctly.

This is an open, ungraded reflection exercise — there is no single correct answer to reveal.

Quick Check

1. Why is debugging/reviewing code a genuinely different skill from writing new code?

Show Answer

It requires actively looking for specific known problem patterns, not just reading code and assuming correctness from a quick glance.

2. What mutable-default-argument check does the review checklist include?

Show Answer

Whether any function uses a mutable object like a list or dict as a default argument value.

3. What exception-handling check does the review checklist include?

Show Answer

Whether exceptions are caught with specific types, rather than a bare except: that could hide genuine bugs.

4. Can code run successfully on an initial test while still containing a genuine bug?

Show Answer

Yes — this is the core point of this lesson; some bugs only reveal themselves under conditions a simple initial test might not cover.

5. What file-safety check does the review checklist include?

Show Answer

Whether files are opened using with, guaranteeing proper closure even if an error occurs.