The Python Bug That Cost Me 2 Days of My Life

A confession about the most embarrassing mistake that taught me the most

It's a mistake nearly every Python developer makes at some point, and it nearly brought down our entire user system.

I thought I was pretty hot stuff. Three years into my Python journey, I was the go-to person on my team for quick scripts and data processing tasks. I'd conquered list comprehensions, mastered decorators, and could write a context manager in my sleep. Then, on a Tuesday that started like any other, Python humbled me in the most spectacular way possible.

The Setup

I was building a simple user preference system. Users could add items to different categories, and if they didn't specify a category, it would default to a general "favorites" list. Clean, straightforward, elegant:

def add_preference(user_id, item, category=[]):
    category.append(item)
    return save_preferences(user_id, category)

I was actually proud of this function. Look at that beautiful default argument! So Pythonic, so concise. I pushed it to staging and moved on to the next task, completely unaware that I'd just planted a time bomb.

The Explosion

The bug reports started trickling in the next day. Users complained that their preferences were getting mixed up with other users' choices. Sarah from marketing found her favorite coffee shops polluted with someone else's restaurant picks. The QA team reported that test data was persisting between test runs in impossible ways.

My first instinct was to blame the database. Obviously, there was some caching issue or a problem with our user isolation. I spent hours diving into database logs, checking our Redis configuration, even questioning whether our load balancer was somehow mixing up sessions. The code was too simple to be wrong, right?

It wasn't until I sat down with a debugger, stepping through the function line by line, that the horrible truth revealed itself. I watched in disbelief as the same list object was being reused across completely different function calls. The memory address didn't change. The id() was identical. The list I thought was being created fresh each time was actually the same list, growing larger and more polluted with each call.

The Realization

In that moment, staring at my screen, I felt like everything I thought I knew about Python was wrong. How could a default argument persist between function calls? It made no logical sense to me. Functions were supposed to be clean, isolated units of logic. Each call should be independent, right?

I did what any desperate developer does at 2 AM: I Googled frantically. That's when I discovered I'd stumbled into one of Python's most famous gotchas. The "mutable default argument" trap that has claimed thousands of victims before me. I wasn't stupid—I was just the latest in a long line of developers to learn this lesson the hard way.

The Education

The explanation, once I found it, was both elegant and infuriating. Python evaluates default arguments exactly once, when the function is defined, not each time it's called. That empty list I thought was so clever? It was created once at import time and then reused for every single function call that didn't provide an explicit argument.

Think of it like this: imagine you're handing out clipboards to different people, but instead of giving each person a fresh clipboard, you're giving everyone the exact same clipboard. When person A writes something on it, person B sees that writing too, because it's literally the same physical object.

This is what happens with mutable objects in Python—objects like lists that can be changed after they're created. Unlike an integer or string, which cannot be modified in place, a list can have items added, removed, or changed. So when multiple function calls all use the same default list, they're all modifying the same shared object in memory.

It's actually a performance optimization. Rather than creating new objects on every function call, Python creates them once and reuses them. For immutable objects like integers or strings, this is harmless—you can't accidentally modify them. But for mutable objects like lists? It's a recipe for exactly the kind of chaos I'd unleashed on my users.

The fix was embarrassingly simple:

def add_preference(user_id, item, category=None):
    if category is None:
        category = []
    category.append(item)
    return save_preferences(user_id, category)

One extra line. That's all it took to fix a bug that had consumed two days of my life and confused dozens of users.

The Humbling

This experience taught me something profound about the nature of expertise. I'd been so confident in my Python knowledge that I'd stopped questioning my assumptions. I'd reached that dangerous middle ground where I knew enough to be productive but not enough to avoid the subtle traps.

The most humbling part? When I finally told my team about the bug, our senior developer just nodded knowingly. "Ah, the mutable default argument," she said with a slight smile. "We've all been there." She'd been bitten by this exact same issue years earlier but had never thought to mention it during code reviews because, well, you don't think to warn people about mistakes you assume they won't make.

The Growth

Now, every time I see a mutable default argument in a code review, I gently point it out. Not with judgment—never with judgment—but with the understanding that comes from having been there myself. I've learned to embrace these moments of ignorance as opportunities for growth rather than sources of shame.

Python's mutable default argument behavior isn't a bug; it's a feature with surprising implications. Understanding it doesn't just make you a better Python programmer—it forces you to think more deeply about how code actually executes, beyond the surface level of syntax and logic.

Sometimes the best lessons come disguised as the most embarrassing bugs. This one taught me that true mastery isn't just about knowing the syntax—it's about understanding the hidden mechanics of the language. It's about questioning your assumptions, especially the ones that seem most obvious.

---

Have you been bitten by this gotcha? Share your story in the comments—we've all been there, and there's no shame in joining the club.

---

Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.