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.

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 ...")