A nightly report generator built 6,800 row buffers by repeating one template list; how do you prove the rows are shared and fix it?

### The symptom and why it misleads The reported failure is that a repair pass over a 6,800-row batch fixes an encoding mismatch on a single row and every other row changes with it. That shape — *a targeted write becomes a global write* — is almost always aliasing, and in Python the most common origin is sequence repetition over a mutable template. The misleading part is that everything before the first mutation looks correct. `len(rows)` is 6,800. Every row has the right shape and the right initial values. A test that builds the batch and asserts on its contents passes. The defect is invisible to equality by construction: a list of 6,800 references to one row compares equal, element by element, to a list of 6,800 genuinely independent rows with identical contents. ### Proving it Identity is the only tool that separates the two. ```python def build_rows(n): template = ["", "utf-8"] return [template] * n rows = build_rows(6800) assert len(rows) == 6800 assert len({id(r) for r in rows}) == 1 assert rows[0] is rows[6799] rows[0][1] = "latin-1" assert rows[6799][1] == "latin-1" ``` The `id()` set is the sharpest instrument: it answers "how many distinct objects are actually in here?" in one expression, and it scales — on a healthy batch it returns 6,800. `rows[0] is rows[-1]` is the fastest smoke test. `sys.getrefcount(rows[0])` returning a number in the thousands rather than a small number is a third confirmation, useful when you only have a REPL attached to a running process and want to check without materialising a set of 6,800 ids. One caution when using `id()` in diagnosis: an id is only unique among **live** objects, so comparing ids of objects that may already have been freed is meaningless. Inside a container that holds every row alive, it is exact. ### Fixing it Build each row where it is needed, so the constructing expression is re-evaluated per row: ```python def build_rows(n): return [["", "utf-8"] for _ in range(n)] rows = build_rows(6800) rows[0][1] = "latin-1" assert rows[6799][1] == "utf-8" assert len({id(r) for r in rows}) == 6800 ``` If a template genuinely seeds each row, copy it per row inside the comprehension — `[list(template) for _ in range(n)]` — so each slot gets its own object. If rows are nested more than one level deep, a per-row shallow copy still shares the level below it, and you either rebuild recursively or use a deep copy. ### The fixes that are not fixes **Copying the outer list.** `rows[:]`, `list(rows)` or an outer-level shallow copy duplicates the pointer array and nothing else; every duplicated pointer still addresses the same row. This is worth being explicit about in the postmortem, because it is the intuitive first patch: ```python rows = [["", "utf-8"]] * 3 outer_copy = list(rows) outer_copy[0][1] = "latin-1" assert rows[2][1] == "latin-1" assert outer_copy[0] is rows[0] ``` **Rebinding the offending row.** Assigning `rows[0] = [...]` fixes exactly one slot and leaves the other 6,799 sharing. The symptom moves rather than disappearing, which is worse than the original bug because it looks fixed. **Calling a factory outside the comprehension.** `[make_row()] * n` is the same defect wearing a helper function: the call runs once and its single result is repeated. The call must be inside the loop. ### Preventing the next one The durable protection is a test that asserts on identity rather than on values, because a value-based test cannot fail on this bug. A single assertion at construction — the number of distinct row ids equals the number of rows — pins the invariant permanently and costs one line. Alongside it, treat `* n` applied to a mutable literal, a call, or a name bound to a mutable object as a review-blocking pattern; it is mechanically greppable, and the failure it produces is silent, delayed and data-corrupting rather than an exception you would catch in staging. Finally, note where the encoding detail fits: it is only the reason someone finally looked. The batch had been carrying one shared buffer for as long as the code existed; every earlier per-row write had been corrupting the batch the same way, and nobody noticed because the writes happened to set every row to the same value anyway.