When would you choose csv.DictReader and csv.DictWriter over csv.reader and csv.writer?

### The choice in one sentence `csv.reader` gives you positional records; `csv.DictReader` gives you named ones. Almost every real file has a header row, and almost every real consumer wants two or three named columns out of twenty, so the dict pair is the default choice and the list pair is the optimisation. ### DictReader mechanics `csv.DictReader(f)` consumes the first record of the file as the header and exposes it as the `fieldnames` attribute. Iterating yields one `dict` per subsequent record, mapping each header name to that record's `str` value. If the file has no header, pass `fieldnames=[...]` explicitly and the first record is then treated as data. Reading `fieldnames` before iteration is what triggers the header read, so it is safe to inspect it up front - useful when you want to fail fast on a file whose columns are not what you expected. Two arguments deal with the fact that real files are ragged: - **`restval=`** is the value used for declared columns a short record does not supply. Without it, missing keys map to `None`, which is a different failure mode from the empty string you get for a present-but-empty field. That distinction matters: `None` means the column was absent, `''` means it was there and blank. - **`restkey=`** names a key under which surplus fields of a long record are collected, as a list. Without it, the extra values are silently discarded. Since Python 3.8, `csv.DictReader` yields ordinary `dict` objects; earlier versions produced `collections.OrderedDict`. Both preserve insertion order, so the change is mostly invisible, but an equality assertion written against `OrderedDict` in an old test will notice. ### DictWriter mechanics `csv.DictWriter(f, fieldnames=[...])` is stricter than its reader, and deliberately so. `fieldnames` is mandatory, because the writer has to decide a column order and it will not guess one from the first dict it happens to see. The header is not written automatically; `writeheader()` is a separate call, so that appending to an existing file does not duplicate it. The strictness that surprises people is `extrasaction`. Its default, `"raise"`, means that passing a row dict with a key outside `fieldnames` raises `ValueError`. That is a feature: it catches the case where an upstream stage started emitting a new field and your output would otherwise have dropped it without a word. When you genuinely want a projection - carrying a wide dict through and writing three columns of it - set `extrasaction="ignore"` and be explicit about the intent. A *missing* key is handled by `restval=` instead, which defaults to the empty string. ### When to stay with the list pair Three situations argue for `csv.reader` and `csv.writer`: 1. **No header.** A file whose columns are defined by an external contract has nothing to key on, and inventing names is not always clearer than indexing. 2. **Volume.** `csv.DictReader` builds a dict per record. Over tens of millions of records that allocation is measurable, and if your loop reads two columns out of thirty, positional access with a couple of indices from the header is faster. Measure before you contort the code. 3. **Genuinely positional work** - transposing, re-emitting a file unchanged, or streaming rows through untouched, where naming the columns adds nothing. ### The habit worth forming Both pairs share the same dialect machinery, the same `newline=''` requirement on the file object, and the same guarantee that every value is a `str`. Choosing between them is a readability and robustness decision, not a correctness one - neither can save you from a column that changed meaning rather than position. One trap deserves naming. Because `DictReader` is keyed by header text, it inherits whatever the header actually says: trailing spaces, a byte-order mark on the first column of a file written by a spreadsheet, an inconsistent case. `row['id']` then raises `KeyError` on a file that looks correct in an editor. Normalising `fieldnames` right after construction - stripping and lower-casing - is a cheap defence, and reading the encoding correctly is what removes the byte-order mark. It is also why an explicit up-front check of `fieldnames` against the columns you require beats discovering the mismatch three million records into a run. ### Reading a headerless file with names anyway The two pairs are not a fork in the road you can only take once. A file with no header can still be read by name: pass `fieldnames=['id', 'lat', 'lon']` to `csv.DictReader` and the first record is treated as data rather than consumed as a header. That is often the better choice when column meanings come from an external contract, because the names then live in one visible place in your code instead of being scattered as bare indices through the loop. The mirror case also holds: `csv.DictWriter` will happily emit a headerless file if you simply never call `writeheader()`, which is what you want when appending to a file that already has one. Neither pair does anything about a column whose *meaning* changed while its name stayed the same, and no amount of dict access will catch that. Name-based access buys robustness against reordering and insertion, which is the common producer-side change; anything beyond that is validation you have to write.