Python Mutable Default Arguments — Data-Leak Gotcha

Python interviews trip up even experienced developers — not because the language is hard, but because interviewers aren't just testing syntax. They're testing whether you understand memory management, mutability traps, the CPython internals that explain quirky behaviour, and whether you can apply the right tool for the right job under pressure. A candidate who can recite list comprehension syntax but can't explain WHY it's faster than a for-loop won't get the role.

This article exists because most interview prep resources give you a list of questions with shallow one-line answers. That's fine for a quiz, but it won't help you when the interviewer follows up with 'why does that happen?' or 'what would you use instead in a production system?' Every answer here explains the mechanism, not just the result — so you can handle follow-ups confidently.

By the end of this article you'll be able to answer all 50 questions with depth, spot the common traps interviewers deliberately set, write clean Python that demonstrates seniority, and walk into any intermediate-to-senior Python interview with genuine confidence rather than crossed fingers.

Why Mutable Default Arguments Are a Data Leak

In Python, default arguments are evaluated once at function definition time, not each time the function is called. This means if you use a mutable object like a list or dict as a default, that single object is shared across all calls. The core mechanic: the default value is bound to the function object itself, stored in __defaults__, and reused every invocation.

When you mutate that default argument inside the function — appending to a list, adding to a dict — the change persists across calls. This is not a bug; it's how Python's object model works. The function signature is compiled once, and the default objects live as long as the function exists. This behavior is deterministic and reproducible, but it violates the assumption most developers make that each call gets a fresh default.

Use this pattern intentionally for caching, memoization, or accumulating state across calls — but never for a parameter that should start empty each time. In real systems, this gotcha silently corrupts data: a list that should be empty for each request accumulates entries from previous requests, leading to hard-to-debug state leaks. The fix is to use None as the default and create a fresh mutable inside the function body.

Memory Management: Mutability and Identity

One of the most frequent 'gotcha' questions in Python interviews concerns the difference between mutable and immutable objects. In Python, everything is an object. Immutable objects (like strings, ints, and tuples) cannot be changed after creation; any 'modification' actually creates a new object in memory. Mutable objects (like lists and dicts) can be changed in place. This distinction is critical when passing arguments to functions, as Python uses 'Pass-by-Object-Reference.'

# io.thecodeforge: Demonstrating the Mutability Trap
def append_to_list(val, my_list=[]):  # DANGEROUS: Default args are evaluated once
    my_list.append(val)
    return my_list

# Production-grade approach
def safe_append(val, my_list=None):
    if my_list is None:
        my_list = []
    my_list.append(val)
    return my_list

print(f"Unsafe 1: {append_to_list(1)}")
print(f"Unsafe 2: {append_to_list(2)}") # Unexpectedly contains [1, 2]

Concurrency and the GIL (Global Interpreter Lock)

For senior roles, you must explain why Python threads don't speed up CPU-bound tasks. The Global Interpreter Lock (GIL) is a mutex that protects access to Python objects, preventing multiple native threads from executing Python bytecodes at once. While this makes memory management simpler, it means for true parallelism in CPU-intensive work, you must use the multiprocessing module to bypass the GIL by using separate memory spaces.

# io.thecodeforge: Parallelism via Multiprocessing
from multiprocessing import Pool
import os

def cpu_intensive_task(n):
    # Simulate heavy computation
    return sum(i * i for i in range(n))

if __name__ == "__main__":
    numbers = [10**6, 10**6, 10**6, 10**6]
    with Pool(processes=os.cpu_count()) as pool:
        results = pool.map(cpu_intensive_task, numbers)
    print(f"Task completed across {os.cpu_count()} cores.")

Generators and Iterators: Lazy Evaluation in Action

Generators are functions that use yield to produce a sequence of values lazily. They pause execution at each yield, preserving state until the next value is requested via next(). This makes them memory-efficient for large datasets and infinite sequences. Iterators are objects that implement __iter__() and __next__(). Python's for loop works by calling iter() on the target and then next() repeatedly until StopIteration is raised. Generators are a special case of iterators generated by functions with yield.

# io.thecodeforge: Custom iterator vs generator for debouncing events
class EventTimestampIterator:
    def __init__(self, timestamps):
        self._timestamps = timestamps
        self._index = 0

    def __iter__(self):
        return self

    def __next__(self):
        if self._index >= len(self._timestamps):
            raise StopIteration
        ts = self._timestamps[self._index]
        self._index += 1
        return ts

# Generator equivalent – more concise
def debounced_events(timestamps, interval_ms=500):
    previous = None
    for ts in timestamps:
        if previous is None or (ts - previous) >= interval_ms:
            previous = ts
            yield ts

# Both produce the same output but generator uses less boilerplate

Decorators: Wrapping Functions for Cross-Cutting Concerns

A decorator is a function that takes another function as argument, extends its behaviour, and returns a new function. Python's @decorator syntax is syntactic sugar for func = decorator(func). Common use cases: logging, authentication, caching, timing, validation. Critical detail: unless you use @functools.wraps, the decorated function loses its original __name__ and __doc__, which breaks introspection and tooling.

# io.thecodeforge: Production-grade timing decorator with @wraps
import functools
import time

def measure_time(func):
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        result = func(*args, **kwargs)
        elapsed = time.perf_counter() - start
        print(f"{func.__name__} took {elapsed:.4f}s")
        return result
    return wrapper

@measure_time
def fetch_user_data(user_id):
    time.sleep(0.2)  # simulate DB call
    return {"id": user_id, "name": "Alice"}

print(fetch_user_data(1))
print(f"Function name preserved: {fetch_user_data.__name__}")

Context Managers and Resource Management

Context managers handle acquiring and releasing resources automatically using the with statement. Built-in examples: file I/O, database connections, locks. You can create custom context managers by defining __enter__ and __exit__ methods on a class, or by decorating a generator function with @contextlib.contextmanager. The __exit__ method receives exception type, value, and traceback — you can choose to suppress exceptions or log them.

# io.thecodeforge: Context manager for database sessions
from contextlib import contextmanager

@contextmanager
def db_session(connection_string):
    conn = create_connection(connection_string)  # not shown
    try:
        yield conn
        conn.commit()  # commit if no exception
    except Exception:
        conn.rollback()
        raise
    finally:
        conn.close()

# Usage — resource is automatically closed
with db_session("postgresql://localhost/mydb") as conn:
    conn.execute("INSERT INTO users ...")

Pass by Object Reference: Why Your Function Mutates the Caller's Data

Junior devs love to argue pass-by-value vs pass-by-reference. The truth is messier: Python uses pass-by-object-reference. The variable name you pass is a reference to an object. If you assign a new value to that name inside the function, the caller doesn't see it. But if you mutate the object the name points to, the caller sees the change. This is why list.append() modifies the original list, but list = new_list does not. Understanding this prevents production bugs where a function unexpectedly corrupts a shared cache or database session state. Always copy mutable objects before modifying them unless you explicitly want side effects.

// io.thecodeforge

def add_item(item, target_list=[]):
    target_list.append(item)
    return target_list

# Production trap: default list is shared across calls
print(add_item('a'))  # ['a']
print(add_item('b'))  # ['a', 'b'] -- not ['b']!

# Safe version: use immutable sentinel
from typing import List, Optional

def add_item_safe(item: str, target_list: Optional[List[str]] = None) -> List[str]:
    if target_list is None:
        target_list = []
    target_list.append(item)
    return target_list

The `__slots__` Directive: Slash Memory Usage Without Changing Logic

Every Python object carries a __dict__ that stores its attributes in a hash map. For thousands of small objects, this overhead kills memory and cache locality. __slots__ tells the interpreter to allocate a fixed-size array for attributes instead of a dictionary. Each slot attribute becomes a descriptor, so attribute access is faster. Use it for data classes, ORM models, or any place you create many instances. The downside: you cannot add new attributes dynamically, and you must declare every attribute in the class hierarchy. Measure before optimizing, but when you have a million objects, __slots__ can cut memory from 50 bytes per instance to under 20.

// io.thecodeforge

class Point:
    __slots__ = ('x', 'y')

    def __init__(self, x: float, y: float):
        self.x = x
        self.y = y

# Try to add a new attribute at runtime
p = Point(1.0, 2.0)
# p.z = 3.0  # AttributeError: 'Point' object has no attribute 'z'

# Memory comparison (rough)
import sys

class DynamicPoint:
    def __init__(self, x, y):
        self.x = x
        self.y = y

d = DynamicPoint(1, 2)
p = Point(1, 2)

print(f"Dynamic: {sys.getsizeof(d)} bytes + dict overhead")
print(f"Slotted: {sys.getsizeof(p)} bytes, no dict")