How do you change a field value on a collections.namedtuple instance?

### Why assignment fails `collections.namedtuple` generates a class whose base is `tuple`, and a tuple's storage is fixed at construction. Each field is exposed as a read-only descriptor over one slot of that storage, so there is no setter to run: ```python from collections import namedtuple Bid = namedtuple("Bid", "campaign cpm_cents") b = Bid("spring-sale", 420) b.cpm_cents = 500 # AttributeError: can't set attribute ``` The generated class also declares an empty `__slots__`, so instances carry no `__dict__`. That closes the usual escape hatch: `b.extra = 1` raises `AttributeError` too, with a message that names the missing `__dict__` explicitly. A namedtuple is immutable in the same sense a tuple is — the record's own bindings cannot be re-pointed. This is deliberate rather than an oversight. Hashability depends on it: because the field values cannot change, `hash(b)` is stable for the object's whole life, which is what makes a namedtuple safe as a dict key or set member. A record type that allowed field mutation could not offer that guarantee without becoming a source of silently corrupted lookups. ### The replacement idiom ```python raised = b._replace(cpm_cents=500) # Bid(campaign='spring-sale', cpm_cents=500) # b is untouched: Bid(campaign='spring-sale', cpm_cents=420) ``` `_replace()` takes **keyword arguments only**, one per field you want to change, and returns a new instance of the same class with every other field copied across. Three details matter in review: 1. **It returns; it does not mutate.** Calling `b._replace(cpm_cents=500)` and discarding the result is a no-op bug, and a common one — it reads like a mutator. The value has to be rebound or stored. 2. **Unknown field names raise.** `b._replace(cpc=500)` raises `TypeError: Got unexpected field names: ['cpc']`. Compare with a dict, where `d["cpc"] = 500` cheerfully invents a key and the typo survives to production. 3. **It is shallow.** If a field holds a list, the new instance shares that same list object with the old one. Mutating it mutates both. For records that must be genuinely independent, either keep the fields immutable (a nested namedtuple, a `frozenset`, a `tuple`) or take a `copy.deepcopy` explicitly. ### Chaining and the alternatives Several fields can be changed in one call: `b._replace(campaign="retarget", cpm_cents=90)`. Chained calls each allocate an instance, so a hot loop that walks a record through five edits allocates five objects; build the final values first and make one call when that matters. Other ways to reach the same place: * `Bid(*old_values)` — positional reconstruction. Works, but every reordering or added field silently breaks it, which is exactly the failure `_replace` exists to prevent. * `Bid(**{**b._asdict(), "cpm_cents": 500})` — verbose, allocates a dict, and loses the unknown-name check. `_replace` does this internally with less ceremony. * `copy.replace(b, cpm_cents=500)` — available since Python 3.13. It is the generic spelling that also works on dataclass instances and several stdlib types, so a helper that must handle more than one record kind can use it uniformly. ### Where this bites in practice Consider an ad-auction bidder that assembles a bid record from a base template, then adjusts it as pacing and floor-price rules apply. If those rules mutated a shared record, a partial-failure rollback would have nothing to roll back to: the pre-adjustment state is gone. With namedtuple records, each rule returns a new instance and the original is still in hand, so unwinding to the last good record is a rebinding rather than an undo log. That is the practical argument for immutable records in any pipeline where you may have to abandon half-applied work. The same property makes concurrency simpler. An immutable record handed to another thread cannot be changed underneath it, so no lock is needed to read it — the coordination problem shrinks to publishing the new reference. ### The related helpers `_asdict()` gives a plain `dict` (an `OrderedDict` before Python 3.8) when you need to hand the record to something dict-shaped. `_fields` is the tuple of field names, useful for writing a CSV header or building a generic diff between two records of the same type. `_make(iterable)` is the inverse of iteration — it constructs an instance from a positional sequence. Together with `_replace` these four are the whole mutation-and-conversion story for tuple-shaped records.