Python's Memory Model Is Not What You Think It Is

Python's Memory Model Is Not What You Think It Is

Ask most Python developers how Python stores a variable and they will say "it stores the value." This is imprecise in a way that causes real bugs and real confusion in interviews. A precise mental model of how Python stores and retrieves data changes how you read and write code.

Python does not store values in variables. Python binds names to objects.

The distinction sounds philosophical until you trace code that involves mutation, function arguments, or aliasing. Then it becomes the most practically useful concept in the language.

Names Are Not Boxes

The box metaphor, which says a variable is a box that holds a value, is how most introductory programming courses explain variables. In many languages this metaphor is close enough to accurate that it does not cause problems.

In Python it is wrong in ways that matter.

A more accurate metaphor: a Python name is a label attached to an object. The object exists independently in memory. Multiple labels can be attached to the same object. Attaching a new label does not move or copy the object.

x = [1, 2, 3]
y = x
print(id(x) == id(y))  # True (same object, two labels)

When you write y = x, you are not copying the list. You are creating a second label that points to the exact same list object.

The Four Operations You Must Distinguish

1. Assignment creates a new binding

x = [1, 2, 3]
x = [4, 5, 6]  # x now labels a completely different object

The first list still exists in memory until garbage collected. The name x simply stops pointing to it and now points to the second list.

2. Mutation modifies an existing object

x = [1, 2, 3]
x.append(4)  # the object x labels is modified in place

Any other name pointing to the same object will instantly reflect this change because they look at the same memory location.

3. Augmented assignment on mutable types mutates

x = [1, 2, 3]
y = x
x += [4, 5]
print(y)  # [1, 2, 3, 4, 5] (same object, mutated)

The += operator on a list calls __iadd__ under the hood, which extends the list in place rather than generating a new collection.

4. Augmented assignment on immutable types rebinds

x = 5
y = x
x += 1
print(y)  # 5 (y still points to the original 5 object)

Integers are immutable. x += 1 cannot modify the integer object 5. Instead, it calculates the result, creates a brand new integer object 6, and rebinds x to it. y remains untouched, still pointing to 5.

Why This Matters in Function Calls

The way Python handles objects dictates exactly how data leaves and enters your functions:

def process(data):
    data = data + [99]  # creates a NEW list, rebinds local name
    return data
def process_mutating(data):
    data += [99]  # mutates the SAME list in place
    return data
original = [1, 2, 3]
result1 = process(original)
print(original)  # [1, 2, 3] (unchanged)

result2 = process_mutating(original)
print(original)  # [1, 2, 3, 99] (mutated)

The only architectural difference is data = data + [99] versus data += [99]. One creates a new object and updates a local label. One mutates the shared underlying object. Both look identical on the surface but produce completely different behavior regarding the original variable.

The Interview Question This Produces

Interviewers combine these behaviors in ways that require a precise mental model to predict:

def modify(items, value=[]):
    value.append(items)
    return value
print(modify(1))
print(modify(2))
print(modify(3))

To predict this output correctly, you need to understand that the default argument value=[] creates exactly one list object at function definition time. The .append() method mutates that single persistent object across all subsequent calls.

Output:

[1]
[1, 2]
[1, 2, 3]

If you got this correct with full confidence, your mental model of Python's execution and storage system is accurate.

Practice Coding Exercises

If you want to build up your code tracing accuracy, try executing these logic flows manually before running them.

Practice problems targeting Python's memory model are available at PyCodeIt, specifically the Medium and Hard dry-run problems involving mutable objects and function arguments. Test your skills at pycodeit.com.

Written by the developer behind PyCodeIt, a free AI-powered Python dry-run practice platform for technical interview preparation.