How to iterate a dict.
keys, values, or items.

What each returns:

d.keys()   → dict_keys view
              yields keys
              supports set operations (a & b, a | b, ...)
              reflects live changes

d.values() → dict_values view
              yields values
              NO set operations (values can be unhashable)
              reflects live changes

d.items()  → dict_items view
              yields (key, value) tuples
              supports set operations (on the tuples)
              reflects live changes

What each view supports:

  keys()   values()   items()
  -----    ------     ------
  len      yes        yes       yes
  in       yes        yes       yes
  iter     yes        yes       yes
  list()   yes        yes       yes
  &        yes        no        yes
  |        yes        no        yes
  -        yes        no        yes
  ^        yes        no        yes

Why values() has no set operations:
  Values can be unhashable (lists, dicts).
  Set operations require hashable elements.
  Keys and items (if keys are hashable)
  satisfy the constraint.
  So values() can't support set operations —
  not every value is hashable.

Why views are not lists:

  ❌ d.keys()[0]   # TypeError — not subscriptable
  ❌ d.keys().sort()  # AttributeError — no sort method

  ✅ list(d.keys())[0]  # convert first
  ✅ sorted(d.keys())  # sort by passing to sorted()
  ✅ sorted(d.items(), key=lambda x: x[1])  # sort items

Views are lazy — no list allocation, no memory overhead.
For most code, that's exactly what you want.

Dict iteration order:

  Python 3.7+: insertion order.
  d = {'b': 1, 'a': 2}
  list(d)  # ['b', 'a']  (not alphabetical, not sorted)

  To sort by key:
    for k in sorted(d):
  To sort by value:
    for k, v in sorted(d.items(), key=lambda x: x[1]):

The default iteration (unsorted) is fast — O(n).
Sorted iteration is O(n log n).

For plain iteration where order doesn't matter,
just iterate. For display or output, sort.

The rule:

You can MODIFY VALUES during iteration:
  for k in d:
      d[k] = d[k] * 2     ✅ works

You CANNOT change SIZE during iteration:
  for k in d:
      d[k + '_new'] = 0   ❌ RuntimeError
      del d[k]             ❌ RuntimeError
      d.clear()            ❌ RuntimeError

Why the restriction:

The dict iterator traverses the underlying hash table.
Changing the size changes the hash table —
which invalidates the iterator's position.
Python can't safely continue.

Same logic as modifying a list while iterating:
  for i in range(len(lst)):
      del lst[i]   # breaks indexing

The safe patterns:

1. Collect keys, then modify
   to_remove = [k for k in d if should_remove(k)]
   for k in to_remove:
       del d[k]

   ✅ Iterate the collected list (not the dict)
   ✅ Dict is untouched during iteration
   ✅ Modification happens after

2. Iterate a copy
   for k in list(d):
       del d[k]
   
   ✅ list(d) creates a snapshot
   ✅ Iterate the list, modify the dict
   ✅ Slightly more memory (a list of keys)
   ✅ Works but less explicit than (1)

3. Build a new dict
   d = {k: v for k, v in d.items() if not should_remove(k)}
   
   ✅ No mutation at all
   ✅ New dict, old one is garbage collected
   ✅ Fastest for "remove all matching" operations
   ✅ Idiomatic Python

4. Iterate keys from a different dict
   for k in other_dict:
       del d[k]
   
   ✅ Not the same dict
   ✅ No conflict

Which pattern to use:

✅ (3) for removing items based on value:
   d = {k: v for k, v in d.items() if v >= 0}

✅ (1) for removing items based on a condition
   that involves calling a function or side effects:
   to_remove = [k for k in d if should_remove(k)]
   for k in to_remove:
       del d[k]

✅ (2) for simple in-place modifications:
   for k in list(d):
       if some_condition(k):
           d[k] = new_value(d[k])

The pattern:
  If you need to CHANGE SIZE, don't iterate the dict.
  Either iterate a copy, or build a new dict.

The RuntimeError is actually helpful:

  dict changed size during iteration

  It tells you exactly what's wrong.
  Without it, you'd get silent corruption —
  skipped items, duplicated items, or crashes
  much later.
  
  The error is a feature.

Same pattern in Java, C#, and other languages:
  modifying a collection while iterating it
  is unsafe.
  Python catches it early.
  In C, you'd get undefined behavior.
  Python is kinder.

The set operations available on .keys() and .items():

  &   intersection — in both
  |   union — in either
  -   difference — in first but not second
  ^   symmetric difference — in exactly one

  Also: isdisjoint, issubset, issuperset
  (as methods)

These work because dict keys must be hashable.
Hashable = can be in a set.
So keys() returns something set-compatible.

What this enables:

1. Compare two configs
   diffs = config1.keys() ^ config2.keys()
   # keys that differ

2. Check required keys
   missing = required - provided
   if missing:
       raise ValueError(f'Missing: {missing}')

3. Find conflicts
   conflicts = defaults.keys() & user.keys()
   # keys present in both

4. Filter by allowed keys
   allowed = {'name', 'age', 'email'}
   filtered = {k: d[k] for k in d.keys() & allowed}

5. Compute permissions
   effective = user_perms | group_perms
   # union of all permissions

6. Find stale keys
   stale = old_config.keys() - new_config.keys()
   # keys that were removed

The .items() set operations:

  (k, v) pairs are hashable IF the key is hashable
  AND the value is hashable.
  
  Example:
    d1 = {'a': 1}
    d2 = {'a': 1}
    d1.items() & d2.items()  # {('a', 1)}
    # Common (key, value) pairs
    
  For dicts with unhashable values (lists, dicts),
  items() can't do set operations.
  
  d1 = {'a': [1, 2]}
  d2 = {'a': [1, 2]}
  d1.items() & d2.items()  # TypeError
  
  The values are lists — unhashable.
  Keys alone still work:
    d1.keys() & d2.keys()  # {'a'}

The .values() exception:
  values() does NOT support set operations.
  Same reason: values can be unhashable.
  
  If you need to compare values as a set,
  convert to a set manually:
    set(d1.values()) & set(d2.values())
  
  But this only works if all values are hashable.
  And it loses the association with keys.
  
  In practice, you rarely need to compare values
  without keys. Use items() if you need both.