In configparser, what does the DEFAULT section do and how does interpolation expand a value?

## Two mechanisms that people conflate `configparser` parses INI-style files, and it has two separate features that both look like "one value coming from somewhere else". Keeping them apart is most of the interview answer. **Defaults** are a *lookup* layer. **Interpolation** is a *substitution* layer inside a single value. They compose, but they are independent: `RawConfigParser` still has defaults and does no interpolation at all. ## The DEFAULT section The section whose name is exactly `DEFAULT` — available as the constant `configparser.DEFAULTSECT` — is special. Every option in it is visible from every other section: ```ini [DEFAULT] root = /srv/media retries = 3 [extract] output = %(root)s/out ``` Here `cfg["extract"]["retries"]` returns `"3"` even though `[extract]` never mentions it. The consequences worth stating out loud: * `cfg.sections()` returns `['extract']`. `DEFAULT` is *not* a section by that method's definition, which trips people writing "loop over every section" code. * Iterating a section proxy, or asking `"retries" in cfg["extract"]`, *does* include the defaults. So `sections()` hides `DEFAULT` while membership tests reveal it. * `cfg.defaults()` returns the defaults mapping directly. * You can also inject defaults programmatically with `ConfigParser(defaults=...)`, which loads them into the same `DEFAULT` layer. * Lookup precedence in `get()` is: the `vars` argument you pass in, then the section, then `DEFAULT`, then `fallback=`. The design cost is that `DEFAULT` leaks everywhere. Once a key is in it, no section can be *without* that key, and "which section actually set this?" stops having a simple answer. For anything but genuinely global fallbacks, an explicit key per section is easier to operate. ## Interpolation `ConfigParser` uses `BasicInterpolation` unless you say otherwise. Substitution happens **on read**, not at parse time: the file stores `%(root)s/out` and `get()` expands it. The name is resolved in the current section, then in `DEFAULT`. Expansion is recursive — a substituted value containing another reference is expanded too — up to a depth limit, beyond which you get `InterpolationDepthError`. Because `%` introduces a reference, a literal percent must be doubled: `discount = 15%%` reads back as `15%`. A stray single `%` is rejected when the value is set, so this fails loudly rather than silently. A reference to a name that does not exist raises `InterpolationMissingOptionError` at read time, which is a genuinely useful property: a typo in a template surfaces the moment the value is used. `ExtendedInterpolation` swaps the syntax and adds cross-section reach: `${option}` for the current section and `${section:option}` for another one, with `$$` as the literal dollar. Choose it when config naturally has a `[paths]` section other sections build on — `BasicInterpolation` simply cannot reference another section. Two escape hatches: construct the parser with `interpolation=None` to store and return values verbatim, or pass `raw=True` to a single `get()` / `items()` call when you want the unexpanded text — for example when you are about to write the file back out. ## Everything is still a string Interpolation and defaults never change the type: a value read from an INI file is `str`, always. Numbers and booleans come back as text, which is why the module ships `getint`, `getfloat` and `getboolean`. That is the other half of using this module correctly. ## Writing, and version history Unlike a TOML parser, `configparser` can write: `cfg.write(fp)` emits the raw, un-interpolated values, so an INI file round-trips (comments are lost). That makes it the standard library's only editable configuration format. Version notes worth knowing: the "magic interpolation" behaviour was made explicit and pluggable in 3.2; `SafeConfigParser` and `LegacyInterpolation` were **removed in 3.12**, so the modern `ConfigParser` with `BasicInterpolation` *is* what the old "safe" parser did; and 3.13 added the ability to accept an unnamed leading section via the `allow_unnamed_section` argument, for files whose first options appear before any header.