Why does inserting a key into a dict during iteration raise RuntimeError?

## The guard, precisely `dict` and `set` are open-addressing hash tables. A `dict` object tracks how many entries it currently holds; when you call `iter(d)`, the iterator stores a copy of that count alongside a cursor into the table. Every call to `__next__` compares the stored count against the container's current count. If they differ, iteration stops with: ``` RuntimeError: dictionary changed size during iteration ``` A set produces the parallel message, `Set changed size during iteration`, and the view iterators from `dict.keys()`, `dict.values()` and `dict.items()` all carry the same guard. ## Why hash containers need the guard and lists do not Inserting into a hash table can trigger a resize: CPython allocates a larger table and re-inserts every entry into it. After that, the cursor an iterator holds refers to a slot in a table that no longer exists in the same shape. Without the check you would get arbitrary results — entries yielded twice, entries never yielded, or a walk over memory that has been freed. Because the failure mode is unbounded rather than merely surprising, CPython pays for a cheap integer comparison per step and turns it into an exception. A list, by contrast, is a contiguous array walked by index. Mutating it during iteration is *defined*: elements shift, the index keeps climbing, and you silently skip or repeat. Wrong, but memory-safe — so list iteration carries no guard at all. That asymmetry is the point of the question: the same class of mistake is loud on a dict and silent on a list. ## What is allowed The guard watches the size, not the contents. This is legal and common: ```python for key in totals: totals[key] = 0 # rebinding an existing key: size unchanged ``` These are not: ```python for key in totals: totals[key + "_raw"] = 0 # insert -> RuntimeError for key in totals: del totals[key] # delete -> RuntimeError ``` There is one nasty corner. Because the check is a size comparison, deleting one key *and* inserting another in the same pass leaves the size equal and slips past that particular check. What you then get is undefined-in-practice behaviour rather than an error: the loop may visit keys you inserted during it, or miss originals entirely. Do not read "no exception" as "supported"; treat the guard as a smoke alarm, not a proof of correctness. Note also that the exception surfaces on the *next* step, not at the moment of mutation. By then the first mutation has already been applied, so a loop that dies this way leaves the container partly modified. Any cleanup pass built this way is not merely broken, it is broken halfway. ## The fixes, and when each is right **Snapshot the keys.** `for k in list(d):` materialises the keys into a real list first, so the loop walks something nobody is mutating and the body is free to delete. It costs one list of N references, which is usually nothing next to the dict itself. This is the smallest edit to broken code and the one to reach for by default. **Two phases.** Collect what to remove, then remove it: ```python stale = [k for k, v in registry.items() if v is None] for k in stale: del registry[k] ``` Slightly longer than the snapshot form, and better when the decision and the deletion deserve to be readable separately, or when you want to log or count what was dropped. **Rebuild.** `d = {k: v for k, v in d.items() if v is not None}` is a single linear pass with no mutation at all, and since Python 3.7 dicts preserve insertion order, so the rebuilt mapping keeps the surviving keys in their original order. The catch is identity: this binds a *new* dict to the name. If other code holds a reference to the old one, either mutate in place instead, or clear and repopulate the original object. **`dict.pop` with a default.** When you are removing keys chosen elsewhere, `d.pop(k, None)` removes without raising if the key is already gone — useful in cleanup paths where two code paths may both prune. ## Concurrency wears the same error The guard does not know *who* changed the size. If one thread iterates a shared dict while another inserts into it, the iterating thread raises `RuntimeError` — intermittently, under load, in a place that looks correct on the page. Diagnosing "dictionary changed size during iteration" in a traceback where the visible loop body plainly does not mutate the dict is the signature of exactly this. The fixes are the same snapshot idiom (`list(d.items())` while holding the lock that guards the mapping) or a proper `threading.Lock` around the whole traversal. ## What a strong answer sounds like Name the mechanism (a size counter recorded at iterator creation and re-checked per step), explain why hash tables need it and lists do not, distinguish value reassignment (legal) from insertion and deletion (not), mention that the container is left partly mutated when the exception fires, and give the snapshot or two-phase fix rather than merely wrapping the loop in `try`/`except`.