Understanding Python Internals and the Memory Model

Understanding what happens under the hood when Python runs your code makes you a dramatically better programmer. You’ll stop being surprised by subtle bugs around object identity, mutation, and shared references — and you’ll write code that’s both correct and efficient from the start.

Everything in Python Is an Object

In CPython (the standard Python implementation), every value you work with — an integer, a string, a function, even a class itself — is a full-blown object stored in memory. Each object carries three pieces of information:

A value — the data it holds (e.g., 42 or "hello")
A type — what the object can do (e.g., <class 'int'>)
An identity — a unique integer representing its memory address, returned by id()

x = 42
print(type(x))   # <class 'int'>
print(id(x))     # e.g., 9788960 — its memory address

def greet():
    return "Hello!"

# A function is also an object — you can inspect it
print(type(greet))    # <class 'function'>
print(greet.__name__) # greet

Because everything is an object, you can assign functions to variables, store them in lists, and pass them as arguments — a foundation for closures, decorators, and functional programming.

Mutable vs Immutable Objects

Python divides objects into two camps. Understanding which camp each type belongs to prevents an entire category of subtle bugs.

Mutable Objects
Immutable Objects

A mutable object can be changed in-place after creation. Its memory address stays the same even when its contents change.Mutable types: list, dict, set, and most custom class instances.

numbers = [1, 2, 3]
print(id(numbers))     # e.g., 4398114048

numbers.append(4)
print(numbers)         # [1, 2, 3, 4]
print(id(numbers))     # 4398114048  ← same address!

Because mutations happen in-place, any variable that references the same object sees the change:

a = [1, 2, 3]
b = a           # b points to the SAME list

b.append(99)
print(a)        # [1, 2, 3, 99] — a was changed too!

An immutable object cannot be modified after creation. Any operation that looks like a modification actually produces a new object at a different memory address.Immutable types: int, float, str, tuple, bool, frozenset.

name = "Alice"
print(id(name))        # e.g., 4398201904

name += " Smith"       # creates a new string object
print(name)            # Alice Smith
print(id(name))        # 4398205424  ← different address

Immutability makes these types safe to share between variables without worrying about accidental mutation.

Mutable objects inside immutable containers: A tuple is immutable — you cannot reassign its elements. But if a tuple holds a mutable object like a list, that list’s contents can still change:

my_tuple = (1, [2, 3])
my_tuple[1].append(4)   # Allowed — modifying the list inside
print(my_tuple)         # (1, [2, 3, 4])

The tuple itself didn’t change (it still holds a reference to the same list object), but the list’s contents did.

Identity (`is`) vs Equality (`==`)

== checks whether two objects have the same value. is checks whether they are the same object in memory — i.e., id(a) == id(b).

list_a = [1, 2, 3]
list_b = [1, 2, 3]   # a new list with equal content

print(list_a == list_b)   # True  — same values
print(list_a is list_b)   # False — different objects in memory
print(id(list_a) == id(list_b))  # False

# Assigning one variable to another creates a shared reference
list_c = list_a
print(list_a is list_c)   # True  — same object

Use == when you care about value, and is only when checking object identity (e.g., if result is None).

CPython integer caching: CPython pre-creates and caches small integers from -5 to 256 to save memory. This means is comparisons on small integers can return True — but don’t rely on this behaviour.

x = 100
y = 100
print(x is y)   # True  — CPython reuses the same object

a = 300
b = 300
print(a is b)   # False — outside the cached range

Always use == to compare values, not is.

Reference Counting and Garbage Collection

CPython tracks how many variables point to each object using a reference count. When you assign an object to a variable, its count goes up. When the variable goes out of scope or is reassigned, the count goes down. When the count reaches zero, Python immediately frees the memory.

import sys

a = [1, 2, 3]      # ref count = 1
b = a              # ref count = 2 (b also points to the same list)

# sys.getrefcount adds 1 temporary reference during the call itself
print(sys.getrefcount(a))  # 3

del b              # ref count drops back to 1
print(sys.getrefcount(a))  # 2

Circular references bypass reference counting. If object A references B and B references A, neither count ever reaches zero — even when both are unreachable from the rest of your program. CPython solves this with a generational garbage collector (gc module) that periodically scans for and destroys circular reference cycles.

import gc

gc.collect()   # Manually trigger a garbage collection cycle

The Global Interpreter Lock (GIL)

The GIL is a mutex inside CPython that ensures only one thread executes Python bytecode at a time. It exists to protect CPython’s reference-counting memory model from race conditions.

What the GIL prevents

Multiple threads cannot corrupt an object’s reference count by incrementing or decrementing it simultaneously — the GIL serialises those operations.

What it means for you

CPU-bound tasks (e.g., number crunching) do not get faster with Python threads because only one thread runs at a time. Use multiprocessing or libraries like NumPy (which release the GIL) instead.

For I/O-bound tasks (network calls, file reads, database queries), threads and asyncio work well because Python releases the GIL while waiting on I/O.

Shallow Copy vs Deep Copy

When you need a copy of a collection rather than a shared reference, you must choose between shallow and deep copying.

import copy

original = [[1, 2], [3, 4]]

# Shallow copy — copies the outer list, but inner lists are still shared
shallow = copy.copy(original)
shallow[0].append(99)
print(original)   # [[1, 2, 99], [3, 4]] — inner list mutated!

# Deep copy — recursively copies everything
original2 = [[1, 2], [3, 4]]
deep = copy.deepcopy(original2)
deep[0].append(99)
print(original2)  # [[1, 2], [3, 4]] — original untouched

When to use shallow copy

Use copy.copy() (or list slicing lst[:]) when your collection contains only immutable objects like strings or numbers. A shallow copy is faster and sufficient because the elements cannot be mutated anyway.

When to use deep copy

Use copy.deepcopy() when your collection contains nested mutable objects (lists of lists, dicts of lists, etc.) and you want a fully independent copy that shares no references with the original.

Practical Implications

Avoid mutable default arguments

Never use a mutable object as a function default argument. The same object is shared across all calls:

# ❌ Bug: the same list is reused every call
def add_item(item, items=[]):
    items.append(item)
    return items

print(add_item("a"))  # ['a']
print(add_item("b"))  # ['a', 'b']  ← unexpected!

# ✅ Correct pattern
def add_item(item, items=None):
    if items is None:
        items = []
    items.append(item)
    return items

Use is None, not == None

None is a singleton — there is exactly one None object in CPython. Use is None and is not None to check for it, not == None.

result = None

if result is None:       # ✅ correct and conventional
    print("No result")

if result == None:       # ❌ works but misleading
    print("No result")

Be deliberate about shared references

When you pass a list to a function, the function receives a reference to the same object. Mutations inside the function affect the caller’s list.

def clear_first(items):
    items[0] = None      # modifies the caller's list

data = [1, 2, 3]
clear_first(data)
print(data)              # [None, 2, 3]

Pass items[:] or copy.copy(items) if you want the function to work on an independent copy.

Python 3.12 introduced a per-interpreter GIL option, and Python 3.13 adds an experimental free-threaded build (--disable-gil). The landscape around the GIL is actively evolving, but for everyday Python the behaviour described here applies.

Core Python

Advanced Python

Pydantic

Understanding Python Internals and the Memory Model

Everything in Python Is an Object

Mutable vs Immutable Objects

Identity (`is`) vs Equality (`==`)

Reference Counting and Garbage Collection

The Global Interpreter Lock (GIL)

What the GIL prevents

What it means for you

Shallow Copy vs Deep Copy

Practical Implications

​Everything in Python Is an Object

​Mutable vs Immutable Objects

​Identity (is) vs Equality (==)

​Reference Counting and Garbage Collection

​The Global Interpreter Lock (GIL)

What the GIL prevents

What it means for you

​Shallow Copy vs Deep Copy

​Practical Implications

Everything in Python Is an Object

Mutable vs Immutable Objects

Identity (`is`) vs Equality (`==`)

Reference Counting and Garbage Collection

The Global Interpreter Lock (GIL)

Shallow Copy vs Deep Copy

Practical Implications