Search across all documentation pages
Python is dynamically typed: a name can refer to different object types over its lifetime, while each object still has a concrete type at runtime. Understanding reference semantics prevents subtle bugs with mutability and shared state.
x = [1, 2, 3]
y = x # same list object
y.append(4)
print(x) # [1, 2, 3, 4]
a: str = "hi"
print(type(a), isinstance(a, str))When to reach for this:
from copy import deepcopy
def demo_references() -> None:
original = {"items": [1, 2]}
alias = original
shallow = original.copy()
deep = deepcopy(original)
alias["items"].append(3)
shallow["items"].append(4)
deep["items"].append(99)
print("original:", original) # items mutated via alias and shallow inner list
print("shallow:", shallow) # top-level dict is new; nested list shared
print("deep:", deep) # fully independent
def demo_dynamic_typing() -> None:
value: int | str = 42
value = "forty-two" # legal - name is not locked to int
print(value, type(value))
if __name__ == "__main__":
demo_references()
demo_dynamic_typing()What this demonstrates:
alias = original shares the dictdict.copy() is shallow - nested mutable objects remain shareddeepcopy recursively duplicates nested structuresint | str but do not enforce types at runtimeint, str, tuple, frozenset cannot change in place; "mutation" creates new objects.list, dict, set change in place; aliases see the same changes.| Category | Examples | Mutable? |
|---|---|---|
| Numeric | int, float, complex, Decimal | No (rebind to change) |
| Text/binary | str, bytes, bytearray | bytearray yes |
| Sequences | list, tuple, range | list yes |
| Mappings | dict | Yes |
| Sets | set, frozenset | set yes |
# id() returns object identity; is compares identity
a = [1]
b = a
c = [1]
print(a is b) # True
print(a is c) # False - different list objects
print(a == c) # True - equal valueslist.copy() and copy.copy() still share nested mutables. Fix: deepcopy when nesting matters.def f(items=[]) reuses one list. Fix: def f(items=None): items = items or [].x = x + [1] creates a new list; x.append(1) mutates in place. Fix: Know which operation you intend.isinstance at boundaries.is vs == for small ints/strings - CPython may intern some literals, but never rely on is for value comparison. Fix: Use == for values, is only for None singleton checks.| Alternative | Use When | Don't Use When |
|---|---|---|
dataclasses with typed fields | Structured records with hints | Simple script variables |
| Pydantic models | Runtime validation at API edges | Inner-loop numeric code |
TypedDict | JSON-shaped dicts with static shape | Objects needing methods |
NamedTuple | Immutable lightweight records | Need mutability |
Both terms appear in docs. Practically: names bind to object references. There are no C-style variables holding raw values on the stack for arbitrary objects.
Both names reference the same list object. Assignment never clones unless you explicitly copy.
No. Use mypy, pyright, or Pydantic when you need enforcement. Hints are stored in __annotations__ but ignored by the interpreter.
type(x) is int fails for subclasses. Prefer isinstance(x, int) for polymorphic checks.
Only if you mutate a shared mutable object. Rebinding a parameter name does not affect the caller's name.
Immutable objects are hashable (when contents are hashable) and safe as dict keys. They also prevent accidental in-place mutation via aliases.
from copy import deepcopy
clone = deepcopy(nested)Debugging identity issues - confirming whether two names point at the same object during troubleshooting.
Yes. Small integers may be cached, but semantically += on immutables rebinds the name to a new object.
When the type is not obvious from the assignment, or when mypy needs help narrowing unions.
Stack versions: This page was written for Python 3.14.0 (stable 3.14, maintenance 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, and uv 0.6+.
Reviewed by Chris St. John·Last updated Jul 19, 2026