Python Object Aliasing & Shared State

Aliasing occurs when two or more names reference the same mutable object in memory. In a trace table, this often looks like identical values in multiple columns, but the key signal is object identity (same memory address), not just value equality.

Representation trick: assign object ids (obj#1, obj#2) in a separate column. When you mutate obj#1, update the shared object's contents rather than copying values into each name column. This prevents a common interview error where candidates accidentally treat aliases as independent values.

Example code:
a = [1, 2, 3]
b = a
b.append(4)
print(a)  # [1, 2, 3, 4]

Trace explanation: both `a` and `b` point to obj#1. When `b.append(4)` mutates obj#1, the change is visible through `a` immediately. In interview narration, explicitly say 'a and b reference the same list object (obj#1) so the append mutates the shared object.'

Production fix patterns: avoid storing mutable defaults in function signatures, prefer copying inputs with `list(x)` or `dict(x)` when you need isolated state, or use immutable types where possible. If high throughput requires mutation for performance, document and constrain ownership semantics clearly in code comments.