The Python Data Model: Names, Objects & Mutability

Every other chapter in this knowledge base tells you what to build. This one tells you what Python is actually doing while you build it — because when a pipeline produces a number nobody can explain, the cause is almost always something in here.

A name in Python is not a box that holds a value. It is a label tied to an object, and two labels can be tied to the same object. Once you internalise that one sentence, a whole family of bugs stops being mysterious: the config that changed after you passed it to a function, the default argument that remembered last week's rows, the copy that was not a copy, the deduplicated set that let a duplicate through.

This is also the highest-density interview chapter in the Python track. "What does this print" rounds are built almost entirely from the material below, and so is the follow-up question after every one of them: why.

object

The actual thing in memory — a list, a dict, an int. It has an identity, a type, and a value.

name

A label bound to an object. Assignment rebinds the label; it does not copy the object.

mutable

The object can be changed in place: list, dict, set, and most classes you write.

immutable

The object cannot be changed: int, float, str, bytes, tuple, frozenset.

identity

Which object this is, tested with `is`. Distinct from equality, tested with `==`.

When you write `totals = {"eu": 100}`, two things happen and they are separate. Python creates a dict object, and then it binds the name `totals` to that object. The name is not the dict. It is a label pointing at it.

`alias = totals` does not build a second dict. It attaches a second label to the same one. There is still exactly one dict, and both names can reach it — so a change made through either name is visible through the other.

This is why `id()` and `is` exist at all. `id(x)` is the identity of the object `x` currently points at, and `x is y` asks whether two names point at the same object rather than at two equal ones.

binding

Attaching a name to an object. `x = y` binds; it does not copy.

rebinding

Pointing an existing name at a different object. Leaves the old object alone.

mutation

Changing an object in place. Visible through every name bound to it.

totals = {"eu": 100}
alias = totals          # a second label, not a second dict

alias["us"] = 250       # mutating through one label...
print(totals)           # ...is visible through the other
print(totals is alias)  # because there is only one object

totals = {"eu": 100}
alias = totals

alias = {"us": 250}     # REBINDS the label alias; the old dict is untouched
print(totals)
print(alias)

The split that matters is not "simple vs complex" — it is mutable vs immutable. A mutable object can be changed in place, so every name bound to it sees the change. An immutable object cannot, so an operation that looks like a change is really building a new object and rebinding.

Immutable: `int`, `float`, `str`, `bytes`, `bool`, `tuple`, `frozenset`, and `None`. Mutable: `list`, `dict`, `set`, `bytearray`, and almost every class you write yourself.

This is why strings feel safe and dicts feel dangerous. You can hand a string to any function in the codebase and know it will come back unchanged, because no function can change it. Hand it a dict and you have no such guarantee.

in place

Modifying the existing object rather than producing a new one.

frozenset

The immutable set. Hashable, so it can be a dict key — an ordinary set cannot.

name = "orders"
before = id(name)
name += "_raw"           # strings are immutable: builds a NEW string
print(before == id(name))

rows = [1, 2]
before = id(rows)
rows += [3]              # lists are mutable: extends IN PLACE
print(before == id(rows))

Aliasing is the practical consequence of everything above: when you pass a mutable object into a function, the function gets a label to your object, not a copy of it. If it mutates, you have been mutated.

This is the single most common way a pipeline config, a shared template or a batch accumulator gets corrupted. The function looks helpful — it takes a config and returns a config — and the return value distracts you from the fact that it also changed the one you gave it.

The fix is a choice, and you should make it explicitly: either the function is documented as mutating its argument (and returns `None`, so nobody misreads it), or it copies at the boundary and returns something new.

alias

A second name bound to an object you already had a name for.

side effect

A change a function makes outside its return value — including mutating its own arguments.

def add_run_id(config, run_id):
    config["run_id"] = run_id     # mutates the CALLER's dict
    return config                 # ...and returns it, which hides that

BASE = {"sink": "warehouse", "retries": 3}
a = add_run_id(BASE, "2026-09-01-a")
b = add_run_id(BASE, "2026-09-01-b")

print(a["run_id"], b["run_id"], BASE["run_id"])
print(a is b is BASE)

def with_run_id(config, run_id):
    return {**config, "run_id": run_id}   # a NEW dict each call

BASE = {"sink": "warehouse", "retries": 3}
a = with_run_id(BASE, "2026-09-01-a")
b = with_run_id(BASE, "2026-09-01-b")

print(a["run_id"], b["run_id"])
print("run_id" in BASE)

A default argument is evaluated **once**, when the `def` statement runs — not on each call. If the default is a mutable object, every call that does not supply that argument shares the same one, for the lifetime of the process.

This is the most-asked Python gotcha in existence, and it is not academic: an accumulator or a "collected errors" list with a mutable default will silently carry rows from one batch into the next, which in a long-running job means a report that grows all day.

The fix is always the same shape: default to `None`, and build the real default inside the function.

sentinel

A stand-in value — usually `None` — meaning "the caller did not supply this".

def time

When the `def` statement executes and the function object is built, as opposed to when it is called.

def collect(row, batch=[]):     # evaluated once, at def time
    batch.append(row)
    return batch

print(collect("r1"))
print(collect("r2"))            # r1 is still there

def collect(row, batch=None):
    batch = [] if batch is None else batch
    batch.append(row)
    return batch

print(collect("r1"))
print(collect("r2"))

There are three levels, and picking the wrong one is the most common cause of "I copied it and it still changed".

**No copy** — `b = a` — two labels, one object. **Shallow copy** — `dict(a)`, `a.copy()`, `{**a}`, `list(a)`, `a[:]` — a new outer container holding the *same inner objects*. **Deep copy** — `copy.deepcopy(a)` — a new outer container and new copies of everything inside it, recursively.

For a flat record — a dict of strings and numbers — shallow is enough, and it is fast. The moment a value is itself a list or a dict, shallow copying gives you a new outer dict that still shares the inner one, which is exactly the surprise this section exists to prevent.

shallow copy

A new container whose elements are the same objects as the original's.

deep copy

A new container whose elements are recursively new objects. Slower, and safe.

import copy

template = {"sink": "warehouse", "columns": ["id", "amount"]}

shallow = dict(template)              # new outer dict, SAME inner list
shallow["columns"].append("region")
print(template["columns"])            # the template changed too

deep = copy.deepcopy(template)        # new outer dict, new inner list
deep["columns"].append("country")
print(template["columns"], deep["columns"])

`==` asks whether two objects have the same value. `is` asks whether they are the same object. They answer different questions and they are not interchangeable, even when they happen to agree.

They happen to agree surprisingly often, which is why this is a bug rather than an error. CPython caches small integers and interns some strings, so `a is b` can be `True` for two separately-written literals — and then `False` for the same values built at runtime.

The rule is short: use `is` only for singletons — `None`, `True`, `False`, and sentinel objects you created yourself. Use `==` for values, always.

interning

CPython reusing one object for certain small ints and short strings. An implementation detail, never a contract.

singleton

A value with exactly one instance in the process — `None`, `True`, `False`, and sentinels you make.

a = 1000
b = int("1000")           # built at runtime, not a shared literal
print(a == b, a is b)

s1 = "order-1042"
s2 = "order-" + str(1042) # built at runtime
print(s1 == s2, s1 is s2)

a = {"id": 7}
b = {"id": 7}
print(a == b)   # same contents
print(a is b)   # different objects
print(a is a)

Dicts and sets find things by hash. That is why only *hashable* objects can be keys or members: Python needs a stable number to look the object up by, and an object that can change cannot provide one.

The contract has two halves and both matter. Objects that compare equal must have the same hash, and an object's hash must not change while it is in a container. Breaking the first makes lookups miss; breaking the second makes them miss intermittently, which is worse.

This is the machinery underneath every dedupe and every lookup map you write. `set()` does not "remove duplicates" — it keeps one object per hash-and-equality group, and if your notion of "duplicate" is not expressed through `__eq__` and `__hash__`, it will not do what you meant.

hashable

Has a `__hash__` that does not change, and an `__eq__` consistent with it. Usable as a key or set member.

hash/eq contract

If `a == b` then `hash(a) == hash(b)`. The reverse need not hold.

seen = set()
seen.add((1042, "A1"))          # a tuple is immutable, so it is hashable
print((1042, "A1") in seen)

try:
    seen.add([1042, "A1"])      # a list can change, so it cannot be hashed
except TypeError as exc:
    print("TypeError:", exc)

class Order:
    def __init__(self, oid):
        self.oid = oid
    def __eq__(self, other):
        return isinstance(other, Order) and self.oid == other.oid

try:
    {Order(1)}                  # no __hash__, so it cannot go in a set
except TypeError as exc:
    print("TypeError:", exc)

Python resolves a name by looking in four places, in order: the **L**ocal function, any **E**nclosing function, the **G**lobal module, and finally the **B**uilt-ins. That is LEGB, and it explains most "why can it see that" questions.

The rule that surprises people is about assignment, not lookup: if a function assigns to a name anywhere in its body, that name is local for the whole function — including on lines *before* the assignment. Reading it first raises `UnboundLocalError` rather than falling through to the global.

`global` and `nonlocal` opt out of that rule, and both are worth knowing and rarely worth using. A function that reaches out to rebind module state is a function you cannot test in isolation.

LEGB

Local, Enclosing, Global, Built-in — the order Python searches for a name.

nonlocal

Rebind a name in the nearest enclosing function scope, not the module.

global

Rebind a name at module level from inside a function. Almost always a design smell in pipeline code.

count = 0

def bump():
    try:
        count += 1        # reads count first -> but count is LOCAL here
    except UnboundLocalError as exc:
        print("UnboundLocalError:", exc)

bump()

A closure is a function that remembers names from the scope it was defined in. The crucial word is *names*: it captures the variable, not the value it had at the moment of definition.

That is why a list of functions built in a loop all return the same thing. Each one closed over the same loop variable, and by the time any of them runs, the loop has finished and that variable holds its final value.

The standard fix is a default argument, which *is* evaluated at definition time — the same mechanism that caused the trouble in the mutable-default section, used deliberately here.

closure

A function plus the enclosing-scope names it refers to.

late binding

Names in a closure are looked up when the function runs, not when it was defined.

makers = [lambda: i for i in range(3)]
print([m() for m in makers])          # all read i AFTER the loop ended

fixed = [lambda i=i: i for i in range(3)]
print([m() for m in fixed])           # default captures i at definition

Every mistake in this chapter shares a profile: no exception, plausible output, and a cause several lines — or several batches — away from the symptom. That is what makes them survive review.

The table below is the review checklist. In an interview, spotting one of these unprompted in somebody else's code is worth more than writing a clever transform.

Four exercises where the data model decides whether your answer is right. None of them is about syntax; each one fails in a way that looks like a logic bug and is actually an aliasing, copying or hashing bug.

Do them with this chapter closed. If one goes wrong, come back to the section named beside it rather than re-reading the whole chapter.