Skip to content

Commit 9ef558e

Browse files
Technologicatclaude
andcommitted
Say why path updates rebuild a named tuple rather than writing into it
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Psmr6ducYKqMi8BYAVzmKM
1 parent fa124c7 commit 9ef558e

1 file changed

Lines changed: 5 additions & 0 deletions

File tree

‎unpythonic/collections.py‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -307,6 +307,11 @@ def _setstep(container: Any, step: Any, item: Any, *, inplace: bool) -> Any:
307307
if step == "cdr":
308308
return cons(container.car, item)
309309
raise AttributeError(f"A cons cell has only the attributes 'car' and 'cdr', got {step!r}.")
310+
# A named tuple is rebuilt even in-place, because it is genuinely immutable: its fields read the tuple's
311+
# item array, and 3.13's `copy.replace` is its `_replace`, a copy. Writing into the item array through
312+
# `ctypes` would work, and would corrupt things: a tuple's hash comes from its contents, so one used as a
313+
# dict key or set member silently goes missing, and CPython shares a constant tuple between every run of
314+
# the line that makes it.
310315
if isinstance(container, tuple) and hasattr(container, "_replace"): # a named tuple's field, by name
311316
return container._replace(**{step: item})
312317

0 commit comments

Comments
 (0)