Layer Settings with ChainMap

Select a timestamp to watch that moment on YouTube.

1. 00:00

   Many programs accept settings from several places. A command-line option should usually override an environment setting, and an environment setting should override a built-in default. That sounds simple until code merges several dictionaries and accidentally gives the default the highest priority. Today we will build a tiny layered configuration using `collections.ChainMap`. It presents multiple mappings as one view and searches them from left to right. We will reproduce a wrong merge, inspect which layer wins, then add validation so a bad port cannot slip through as a string. We will also check what happens when one of the original dictionaries changes after

2. 00:41

   the `ChainMap` is created. That detail matters because `ChainMap` is a live view, not a frozen copy of all values. The examples are entirely local and work with ordinary Python dictionaries. You can edit the priorities and run the code on the lesson page. Keep the policy in mind: we want command line, then environment, then defaults. The loop starts with the strongest override and ends with defaults. But `dict.update` replaces existing keys with later values, so the last layer wins. By the end, the default port eight thousand has overwritten both higher- priority choices.

3. 01:21

   This is a straightforward bug because the source order appears to match the intended precedence when read from left to right. One repair would reverse the update order. That can be fine for a small immutable configuration, but it creates a merged copy and hides which mapping supplied a value. It also will not reflect later changes to an underlying layer. For this lesson, we want the lookup order to be explicit. The effective configuration should first check command-line overrides, then the environment dictionary, then defaults. The fact that the printed dictionary includes the default host does not make the port correct. Testing only that a key exists would miss this precedence mistake; we need a key

4. 02:04

   that appears in multiple layers. `ChainMap` stores references to the supplied mappings. A lookup checks them in the order we passed them. The first port is nine thousand because the command-line mapping has the key. The host falls through to defaults because the first two mappings have no host. Then we delete the command-line port from its original dictionary. The very next lookup yields eight thousand eighty from the environment layer. We did not rebuild the `ChainMap`; it is a view over live mappings. This is useful when settings should reflect an updated override, but it can surprise you if you expected a snapshot.

5. 02:44

   If you need an immutable configuration at program startup, copy and validate the effective values into a separate object. Another important rule: assignment through a `ChainMap` normally writes to its first mapping, not to whichever layer originally held the key. A reader may see a default, but a write of that key goes into the override layer. We will use that behavior deliberately in the final verification. The helper states the priority at its construction line: command line first, environment second, defaults last. It then converts the effective value to an integer and checks the valid port range.

6. 03:24

   The command-line and environment examples arrive as strings, which is common when reading arguments or environment variables. Conversion happens after precedence resolution, so we validate the value that the application will actually use. We also provide a specific error message when conversion fails and chain the original exception for debugging. A real application might choose a dataclass or a typed configuration object to store the final validated settings. This small function returns only the port to keep the demonstration focused. It is important not to treat `ChainMap` itself as a validation framework; it only defines lookup order.

7. 04:06

   If the first layer contains an invalid value, it does not automatically skip it and try a lower-priority layer. That would hide a user mistake. We reject the invalid override instead of silently falling back to a different port. The first assertion finds the environment port because there is no command-line override yet. Assignment through `config` writes into the first mapping, so the command-line dictionary now contains nine thousand while the environment dictionary remains unchanged. Deleting that new key reveals the environment port again. This sequence is a direct test of the live view behavior, not merely of the value returned in one static case.

8. 04:49

   The final conversion demonstrates that an invalid string should trigger a visible error. In a complete application, the validation helper from the previous chapter would handle that error. Try inserting a command-line value of zero and predict whether a lookup or the validator will reject it. `ChainMap` will happily return zero; the validator must enforce the port range. Try changing the order of the mappings and observe how the effective value changes. When you finish the interactive task, you should be able to state both rules: earlier mappings have higher lookup priority, and writes through a normal `ChainMap` target its first mapping.

9. 05:30

   Use a copy when you need a frozen, validated snapshot rather than a live layered view.