Python Mutable Defaults — Why Users Saw Each Other's Errors

Python is famous for being beginner-friendly, and that reputation is well-earned. But 'easy to start' doesn't mean 'impossible to mess up.' In fact, Python's clean syntax can lull you into a false sense of security — you write code that looks perfectly sensible, hit run, and get results that are completely wrong with no error message to warn you. These silent bugs are the most dangerous kind, because you don't even know something went wrong.

Most Python mistakes aren't random. They cluster around a handful of concepts that trip up beginners and even intermediate developers: how Python handles mutable objects, how it compares values versus identities, how indentation creates scope, and how default arguments are evaluated. Each of these is a 'gotcha' built into the language's design — not bugs in Python, but features that behave differently from what newcomers expect.

By the end of this article you'll be able to look at a piece of Python code and immediately spot these hidden traps. You'll understand WHY each mistake happens — not just what the fix is — so you can reason about new code confidently. We'll use real runnable examples, show you the exact wrong output and then the corrected version, and finish with the interview questions recruiters love to ask about exactly this stuff.

Why Mutable Defaults Corrupt Shared State

A mutable default argument in Python is an object (like a list or dict) that is created once at function definition time, not each time the function is called. This means every call that omits that argument shares the same underlying object. The core mechanic: Python evaluates default arguments when the def statement executes, not when the function is invoked. So def f(x=[]) creates a single list object stored in f.__defaults__. Each call that relies on the default mutates that same list, accumulating state across calls. This is a classic gotcha because it violates the assumption that each call gets a fresh default. In practice, this bites teams when a web handler or background worker uses a mutable default to accumulate errors or user data. Two users hit the same endpoint: the first triggers an error appended to the default list, the second sees that error as their own. The symptom is intermittent, non-reproducible bugs that vanish when you add logging or restart the process. The rule of thumb: never use a mutable object as a default argument. Use None instead, and assign a fresh mutable inside the function body.

The Mutable Default Argument Trap — Python's Most Surprising Bug

Here's one that catches almost everyone. When you define a function with a default argument like def add_item(item, cart=[]), you might think Python creates a fresh empty list every time the function is called without a second argument. It doesn't. Python creates that default list exactly once — when the function is defined — and reuses the same list object every single time.

Think of it like a sticky notepad on your desk. You write a reminder on it, tear off the note, but the impression is still on the next page. Each function call writes on the same pad. This is because in Python, default argument values are stored as part of the function object itself, not re-evaluated on each call.

This is one of the most common Python bugs in production code. The fix is simple but important: use None as the default value, then create a new list inside the function body if the caller didn't provide one. This ensures every call that needs a fresh list actually gets one.

Here's the deeper reason: Python evaluates default arguments at definition time, not call time. That's by design — it avoids recalculating expensive default values repeatedly. But for mutable objects, this efficiency creates a shared-state bug that becomes a data corruption vector in multi-threaded or concurrent environments.

# ============================================================
# WRONG VERSION — using a mutable list as a default argument
# ============================================================
def add_to_cart_broken(item, cart=[]):
    # Python creates this [] ONCE when the function is defined
    # Every call that omits 'cart' shares the SAME list object
    cart.append(item)     # We're modifying the one shared list
    return cart

print("--- Broken version ---")
first_order = add_to_cart_broken("apple")
print(f"First order: {first_order}")   # Looks fine so far

second_order = add_to_cart_broken("banana")
print(f"Second order: {second_order}")  # Wait — why is apple here?!

print(f"First order now: {first_order}")  # Even first_order changed!


# ============================================================
# CORRECT VERSION — use None as the sentinel, build inside
# ============================================================
def add_to_cart(item, cart=None):
    # None signals "no cart was provided" — a safe, immutable default
    if cart is None:
        cart = []         # Create a BRAND NEW list for this call only
    cart.append(item)
    return cart

print("\n--- Fixed version ---")
first_order = add_to_cart("apple")
print(f"First order: {first_order}")    # ['apple']

second_order = add_to_cart("banana")
print(f"Second order: {second_order}")  # ['banana'] — clean!

print(f"First order still: {first_order}")  # ['apple'] — untouched

== vs is — Equality Versus Identity (They Are Not the Same Thing)

Imagine twins who look identical. If you ask 'do they look the same?' the answer is yes. But if you ask 'are they the same person?' the answer is no. That's exactly the difference between == and is in Python.

== checks if two values are equal — like asking 'do these two things look the same?'. is checks if two variables point to the exact same object in memory — 'are these two variables the same physical thing?'. For beginners, these feel interchangeable. They're not, and using is where you mean == creates silent bugs that are very hard to track down.

The most dangerous version of this mistake is checking if some_variable is 'hello' instead of if some_variable == 'hello'. For small integers (-5 to 256) and short strings, Python caches the objects — so is accidentally works. But for larger values or strings built at runtime, it breaks without warning. Always use == for value comparison. Reserve is exclusively for checking against None, True, and False.

One nuance: interning is an implementation detail. CPython interns integer literals in a certain range and small strings that look like identifiers. Other Python implementations (PyPy, Jython) may not. Relying on is for value comparison is undefined behaviour across implementations.

# ============================================================
# Demonstrating == (equality) vs is (identity)
# ============================================================

# --- Lists: same contents, different objects ---
shopping_list_a = ["milk", "eggs", "bread"]
shopping_list_b = ["milk", "eggs", "bread"]

print("--- List comparison ---")
print(shopping_list_a == shopping_list_b)  # True  — same CONTENTS
print(shopping_list_a is shopping_list_b)  # False — different OBJECTS in memory

# --- Integers: Python's small integer cache can mislead you ---
small_number_a = 42
small_number_b = 42
print("\n--- Small integer (cached by Python) ---")
print(small_number_a == small_number_b)  # True
print(small_number_a is small_number_b)  # True — only because Python CACHES -5 to 256

big_number_a = 10000
big_number_b = 10000
print("\n--- Large integer (NOT cached) ---")
print(big_number_a == big_number_b)  # True
print(big_number_a is big_number_b)  # False — now they ARE different objects!

# --- The correct pattern: use 'is' ONLY for None checks ---
user_input = None

if user_input is None:          # CORRECT — this is the right use of 'is'
    print("\nNo input received — please enter a value")

if user_input == None:          # WORKS but considered bad style in Python
    print("This also works, but PEP8 prefers 'is None'")

# --- String comparison: never use 'is' for strings you build ---
first_name = "Alice"
search_term = "".join(["Al", "ice"])  # Built at runtime

print("\n--- Runtime string comparison ---")
print(first_name == search_term)  # True  — values match
print(first_name is search_term)  # False — different objects (usually)

Modifying a List While Iterating Over It — The Vanishing Items Bug

Picture a queue of people at a coffee shop. You're going through the line one by one, and as you skip someone you don't like, you push everyone behind them one step forward. Now the person who was second is in first position — and you've already moved past first position. You just skipped someone without realising it.

That's exactly what happens when you remove items from a Python list while looping over it with a for loop. Python tracks your position in the list by index. When you delete an element, every element after it shifts one position to the left. Python moves forward anyway — skipping the element that just slid into the deleted slot. Items silently disappear from your processing.

The clean fix is to iterate over a copy of the list using list[:] or list(original), or better yet, use a list comprehension to build a new filtered list. List comprehensions aren't just stylistically preferred — they're actually the safest, most readable solution to this exact problem.

This bug is insidious because it only removes some items, not all, making the output inconsistent and hard to reproduce. Debugging often involves printing intermediate states to discover the skipped element.

# ============================================================
# WRONG — removing items from a list while looping over it
# ============================================================
temperature_readings = [22, -5, 30, -1, 18, -8, 25]
print(f"Original readings: {temperature_readings}")

for reading in temperature_readings:
    if reading < 0:  # Try to remove all negative (faulty) readings
        temperature_readings.remove(reading)  # This shifts the list!

# Notice -1 survived! It slid into the slot where -5 was removed,
# and Python's iterator had already moved past that index.
print(f"After (broken) cleanup: {temperature_readings}")
print("Notice -1 was NOT removed — it slipped through!")


# ============================================================
# CORRECT approach 1 — iterate over a COPY of the list
# ============================================================
temperature_readings = [22, -5, 30, -1, 18, -8, 25]  # Reset

for reading in temperature_readings[:]:   # [:] creates a shallow copy
    if reading < 0:
        temperature_readings.remove(reading)  # Safe — we're iterating the copy

print(f"\nAfter (copy) cleanup: {temperature_readings}")


# ============================================================
# CORRECT approach 2 — list comprehension (cleanest, most Pythonic)
# ============================================================
temperature_readings = [22, -5, 30, -1, 18, -8, 25]  # Reset

# Build a NEW list containing only valid readings
valid_readings = [r for r in temperature_readings if r >= 0]

print(f"Valid readings (list comprehension): {valid_readings}")
# This is the preferred approach — readable, safe, and efficient

Misunderstanding How Python Copies Objects — Shallow vs Deep Copy

Imagine photocopying a folder. A shallow copy gives you a new folder with photocopies of the cover pages, but the pages inside still reference the originals — change a page inside, and both folders show the change. A deep copy photocopies every single page, so the two folders are completely independent.

In Python, when you assign one list to another variable with new_list = old_list, you haven't copied anything at all. You've given the same list a second name. Both variables point to the identical object. Change one and you change both.

Even new_list = old_list[:] only creates a shallow copy — which is fine for a flat list of numbers or strings, but fails for a list of lists. The nested inner lists are still shared. For true independence, you need copy.deepcopy() from Python's built-in copy module. Knowing when to use each is a sign of genuine Python understanding.

Performance note: deepcopy() is slower because it recursively copies every object. For large nested structures, consider whether you need full independence or can design your data to use immutable types.

import copy  # Python's built-in module for copying objects

# ============================================================
# MISTAKE 1 — assignment is NOT a copy
# ============================================================
original_scores = [95, 87, 76, 88]
aliased_scores = original_scores  # This is NOT a copy — same object!

aliased_scores.append(100)  # Modifying through the alias...
print(f"Original (should be unchanged): {original_scores}")
# Surprise — original changed too!


# ============================================================
# SHALLOW COPY — fine for flat structures
# ============================================================
original_scores = [95, 87, 76, 88]  # Reset
shallow_copy = original_scores[:]   # Creates a new list...

shallow_copy.append(100)             # This only affects shallow_copy
print(f"\nOriginal after shallow copy append: {original_scores}")
print(f"Shallow copy: {shallow_copy}")


# ============================================================
# WHERE SHALLOW COPY FAILS — nested lists
# ============================================================
classroom_grades = [[90, 85, 88], [72, 78, 80], [95, 91, 93]]
shallow_classroom = classroom_grades[:]  # Shallow copy of outer list

# Modifying a nested list through the copy...
shallow_classroom[0].append(99)  # This changes the SHARED inner list!

print(f"\nOriginal classroom (should be unchanged):")
print(classroom_grades)  # The inner list changed — shallow copy problem!


# ============================================================
# DEEP COPY — full independence at every level
# ============================================================
classroom_grades = [[90, 85, 88], [72, 78, 80], [95, 91, 93]]  # Reset
deep_classroom = copy.deepcopy(classroom_grades)  # Copies everything recursively

deep_classroom[0].append(99)  # Modifying the deep copy's inner list

print(f"\nOriginal after deep copy modification:")
print(classroom_grades)   # Unchanged!
print(f"Deep copy:")
print(deep_classroom)     # Only the copy changed

Variable Scope and the LEGB Rule — Why Your Function Can't See the Variable

Python resolves variable names using the LEGB rule: Local, Enclosing, Global, Built-in. When you assign a value to a variable inside a function, Python assumes it's a local variable unless you explicitly declare it global (or nonlocal for nested functions). This leads to one of the most confusing errors for beginners: UnboundLocalError: local variable 'x' referenced before assignment.

Here's the trap: you have a global variable defined outside, and inside a function you try to modify it. Python sees the assignment and marks the variable as local. But if you also reference the variable before the assignment (e.g., print(x) then x = x + 1), Python throws an UnboundLocalError because the local x hasn't been assigned yet, even though a global x exists.

This is not a bug in Python — it's a deliberate design to prevent accidental modification of global state. The fix: either use global var_name to indicate you want to modify the global, or better, pass the variable as a parameter and return the updated value. Functions should avoid modifying globals whenever possible.

# ============================================================
# WRONG — trying to modify a global variable without global
# ============================================================
counter = 0

def increment_wrong():
    # Python sees 'counter =' and marks it as local
    # But we reference it before assignment: counter = counter + 1
    # This raises UnboundLocalError
    try:
        counter = counter + 1
    except UnboundLocalError as e:
        print(f"Error: {e}")

increment_wrong()


# ============================================================
# CORRECT — use 'global' to declare intent
# ============================================================
def increment_correct():
    global counter
    counter = counter + 1

increment_correct()
print(f"Counter after global fix: {counter}")


# ============================================================
# BETTER — avoid globals, use parameters and return values
# ============================================================
def increment_best(counter):
    return counter + 1

counter = 0
counter = increment_best(counter)
print(f"Counter after functional fix: {counter}")


# ============================================================
# ENCLOSING SCOPE (nonlocal) for nested functions
# ============================================================
def outer():
    count = 0
    def inner():
        nonlocal count
        count += 1
        return count
    return inner

counter_fn = outer()
print(f"Enclosing scope test: {counter_fn()}, {counter_fn()}")

Using Class Variables When You Meant Instance Variables — Shared State Surprise

A common object-oriented mistake is defining a mutable attribute directly in the class body (a class variable) and then modifying it on instances. Class variables are shared across all instances. If you modify a class variable through one instance, every instance sees the change — unless you accidentally create an instance variable with the same name.

Beginners often define a list or dict in the class body expecting each instance to get its own copy. But class variables are attached to the class itself, not to instances. When you access self.items and it doesn't exist on the instance, Python finds the class variable. If you assign to self.items (e.g., self.items.append(...) or self.items = ...), the behaviour differs: mutation finds the shared object, assignment creates a new instance variable that shadows the class variable.

The fix: define mutable defaults in __init__ using self.items = [] rather than in the class body. If you need a class-level constant, use immutable types like tuples or strings.

# ============================================================
# WRONG — class variable shared across instances
# ============================================================
class ShoppingCart:
    items = []  # This is a class variable, shared by all instances!

    def add(self, item):
        self.items.append(item)  # Mutates the shared class variable

cart1 = ShoppingCart()
cart1.add("apple")
cart2 = ShoppingCart()
cart2.add("banana")

print(f"cart1.items: {cart1.items}")  # ['apple', 'banana'] — includes cart2's item!
print(f"cart2.items: {cart2.items}")  # ['apple', 'banana']
print(f"Same list object? {cart1.items is cart2.items}")  # True


# ============================================================
# CORRECT — instance variable created in __init__
# ============================================================
class ShoppingCartFixed:
    def __init__(self):
        self.items = []  # Each instance gets its own list

    def add(self, item):
        self.items.append(item)

cart_a = ShoppingCartFixed()
cart_a.add("apple")
cart_b = ShoppingCartFixed()
cart_b.add("banana")

print(f"\ncart_a.items: {cart_a.items}")  # ['apple']
print(f"cart_b.items: {cart_b.items}")  # ['banana']
print(f"Same list object? {cart_a.items is cart_b.items}")  # False

The Bare Except Trap: Swallowing KeyboardInterrupt and Your Sanity

You see a bare except: in code review and you should flag it immediately. This catches absolutely everything — including KeyboardInterrupt, SystemExit, and GeneratorExit. Hit Ctrl+C to stop a runaway script? Swallowed. Your app tries to shut down gracefully? Buried. Worse, bare excepts hide your own bugs. A typo in a variable name inside a try block becomes a silent no-op instead of a clear NameError. The code looks like it works, but it's lying to you. Always catch specific exceptions. If you truly need a safety net, use except Exception: — that still catches almost everything you'd want to catch, but lets KeyboardInterrupt and SystemExit propagate. And never, ever use except: pass. That's not error handling. That's code that gaslights you into thinking your application is stable when it's one bad input away from complete nonsense.

import time

def query_database():
    # Simulate a long-running query
    time.sleep(10)
    return [{"id": 1, "name": "Alice"}]

try:
    results = query_database()
    # Typo: 'result' instead of 'results'
    print(f"Fetched {len(result)} records")
except:
    pass  # Silently swallows NameError
print("Script finished — but did it work?")

The 'Lazy' Import That Breaks Code at 2 AM

I see this pattern everywhere: from module import *. It looks convenient. It's a ticking time bomb. When you star-import, you dump every public name from that module into your namespace. Tomorrow, that module updates and adds a function called calculate(). Guess what? Your local calculate() is now silently overwritten. No error. No warning. Your function now returns completely different results. Tests pass because they ran with the old version. Production breaks at 2 AM because someone ran pip install --upgrade. The fix is trivial and mandatory: import exactly what you need, or use the module namespace explicitly (import module; module.function()). It's more typing. It's infinitely more maintainable. Your future self — awake at 2 AM — will thank you.

# internal_tools.py
def calculate(x):
    return x * 2

# main.py
from internal_tools import *

def calculate(x):
    # Intent: complex business logic
    return x * 100

result = calculate(5)
print(f"Result: {result}")
# Is this 10 or 500? Depends on import order.