Variables, Objects & Dynamic Typing¶

Estimated time: 22 min read · Part: Values, Variables & Expressions

In Python, everything is an object — a number, a string, a function, even a type itself. A variable is simply a name bound to an object stored in memory. This is different from languages like C, where a variable is a fixed-size box allocated at a memory address, and assignment copies the value into the box. In Python the name and the object are separate things, and the name can be re-pointed at any time without affecting the underlying object or any other names that happen to reference it.

This single distinction — name vs. object, reference vs. copy — is the source of the most common class of Python surprises for people who learned in other languages. Understanding it deeply, not just intellectually, prevents a whole category of bugs before you write them. The next several code examples build the complete picture.

x = 42           # name 'x' binds to the int object 42
x = "hello"     # x re-binds to a str object; 42 is now unreferenced
y = x            # y binds to the SAME object x points at

print(id(x))               # memory address of the object
print(id(y))               # same address — one object, two names
print(id(x) == id(y))     # True
print(x is y)             # True — 'is' checks identity (same object)

# Rebind x — y is unaffected:
x = "world"
print(y)                  # still "hello" — the object didn't change

140234891234560 140234891234560 True True hello

The aliasing trap: mutable objects¶

The sticky-note model matters most with mutable objects — objects whose contents can change in place. Lists, dictionaries, and sets are mutable. When two names point at the same mutable object, a mutation through one name is visible through the other. This is called aliasing and is the canonical Python gotcha.

a = [1, 2, 3]
b = a            # b points at THE SAME list object

b.append(4)       # mutates the shared object
print(a)         # [1, 2, 3, 4] — a sees the change
print(a is b)    # True

# To get an INDEPENDENT copy, copy explicitly:
c = a.copy()       # or: list(a), or a[:]
c.append(99)
print(a)         # [1, 2, 3, 4] — unchanged
print(c)         # [1, 2, 3, 4, 99]
print(a is c)    # False — different objects now

[1, 2, 3, 4] True [1, 2, 3, 4] [1, 2, 3, 4, 99] False

import copy

original = [[1, 2], [3, 4]]
shallow  = original.copy()    # outer list is new; inner lists are shared
deep     = copy.deepcopy(original)

original[0].append(99)

print(original)   # [[1, 2, 99], [3, 4]]
print(shallow)    # [[1, 2, 99], [3, 4]] — inner list shared, sees change
print(deep)       # [[1, 2], [3, 4]]    — fully independent

[[1, 2, 99], [3, 4]] [[1, 2, 99], [3, 4]] [[1, 2], [3, 4]]

Dynamic typing, strong typing, and type()¶

Python is dynamically typed: a name has no fixed type — the object it points to carries the type, and a name can be re-bound to a differently-typed object at any time without error. A variable named value might hold an int in one execution path and a str in another, and Python's runtime only sees the type when the relevant instruction executes.

But Python is also strongly typed: it won't silently coerce incompatible types behind your back. Adding a string to an integer raises a TypeError instead of guessing what you meant. This distinguishes Python from weakly-typed languages like JavaScript ("5" + 5 gives "55") or Perl. Strong typing means you get clear errors when types are wrong rather than silent nonsense results that are hard to trace.

value = 42
print(type(value))          # <class 'int'>

value = "hello"             # re-bind to a str — perfectly valid
print(type(value))          # <class 'str'>

# Strong typing: operations must make sense
try:
    result = "age: " + 7     # TypeError — can't add str and int
except TypeError as e:
    print(e)                 # can only concatenate str (not "int") to str

result = "age: " + str(7)  # fix: explicit conversion
print(result)               # age: 7

# isinstance() for runtime type checks:
print(isinstance(value, str))         # True
print(isinstance(value, (str, int)))  # True — accepts a tuple of types

can only concatenate str (not "int") to str age: 7 True True

Identity vs equality, and None¶

Two operators look similar but mean very different things. == checks whether two objects have the same value (it calls the __eq__ method). is checks whether two names point to the same object in memory (identity). For most values, you want ==. The canonical exception is None: always write if x is None:, never if x == None:. This is a style convention (PEP 8) and a correctness safeguard — a custom class can define __eq__ to return True when compared to None, but is is not fooled.

a = [1, 2, 3]
b = [1, 2, 3]   # same value, different object
print(a == b)   # True  — same value
print(a is b)  # False — different objects

# None is a singleton — exactly one object exists
x = None
print(x is None)    # True  — correct idiom
print(x == None)   # True  — works, but not idiomatic; avoids __eq__ override

# Small integer caching — CPython caches -5 to 256
p = 256; q = 256
print(p is q)       # True  (cached object)
r = 257; s = 257
print(r is s)       # False or True (implementation-dependent!)
# ⚠ Never use 'is' to compare integers — this is a known interview trap

True False True True True False

  PYTHON REFERENCE MODEL
  ═══════════════════════════════════════════════════

  After: a = [1,2,3]; b = a; c = a.copy()

  Name table          Object heap
  ──────────          ────────────────────────────────
   a ──────────────► [1, 2, 3]  (id: 0x7f1a)
   b ──────────────► [1, 2, 3]  (id: 0x7f1a) ← same object!
   c ──────────────► [1, 2, 3]  (id: 0x8c3b) ← different object

  a.append(4):  heap changes to [1, 2, 3, 4]
    a sees: [1, 2, 3, 4]  ✓
    b sees: [1, 2, 3, 4]  ← aliased, sees change!
    c sees: [1, 2, 3]     ✓ (independent copy)

Naming conventions, del, and reference counting¶

Python names follow PEP 8 conventions. The standard is snake_case for variables and functions, UPPER_SNAKE_CASE for module-level constants, and PascalCase for class names. Leading underscores carry convention meanings: _private means "treat as internal," and __dunder__ (double underscore) names are Python's protocol methods (__init__, __len__, etc.).

The del statement removes a name binding from its namespace — it doesn't necessarily destroy the object. Objects are destroyed (garbage collected) when their reference count drops to zero. CPython uses reference counting as its primary garbage collection mechanism, supplemented by a cycle collector for circular references. In practice you rarely call del explicitly — Python's GC handles memory automatically — but understanding it explains why objects sometimes linger longer than expected (e.g., a closed file that still has a reference in a list).

WHY names bind to objects, not values This model makes Python extremely flexible: the same name can hold different types at different times, functions can be passed as values, and objects can be built dynamically. It also makes garbage collection straightforward — count the references, destroy when zero. The cost is aliasing surprises with mutable objects, which is why functional programmers prefer immutable data structures (tuples, frozensets) for shared data.

HOW to avoid aliasing bugs in practice Three reliable techniques: (1) Return a new object instead of mutating in place — functional style. (2) When you must share mutable state, make it explicit with a class and controlled mutation methods. (3) Use .copy() or copy.deepcopy() when you need independence. The is operator and id() are your debugging tools when something unexpected mutates.

WHERE aliasing trips people up in consulting work Pandas DataFrames exhibit exactly this pattern: df2 = df[df['col'] > 5] may return a view (aliased) or a copy depending on the operation, causing the infamous SettingWithCopyWarning. The fix (.copy()) is the same. DataFrame aliasing bugs are among the most common in data analysis scripts passed between teams.

def safe_update(record: dict, updates: dict) -> dict:
    """Return a new dict with updates applied; original is never touched."""
    return {**record, **updates}   # dict unpacking creates a new object

def unsafe_update(record: dict, updates: dict) -> dict:
    """Mutate record in place and return it — dangerous pattern."""
    record.update(updates)
    return record

# Test safe:
original = {"name": "Acme", "tier": "gold"}
result = safe_update(original, {"tier": "platinum", "mrr": 5000})
print("original after safe_update:", original)
# {'name': 'Acme', 'tier': 'gold'}  — unchanged
print("result:", result)
# {'name': 'Acme', 'tier': 'platinum', 'mrr': 5000}

# Test unsafe:
original2 = {"name": "Globex", "tier": "silver"}
result2 = unsafe_update(original2, {"tier": "gold"})
print("original after unsafe_update:", original2)
# {'name': 'Globex', 'tier': 'gold'}  — mutated!
print("same object:", original2 is result2)
# True