Worked examples — Nested data structures — list of dicts, dict of lists

Before any example we agree on our running data so every symbol is earned:

students_lod = [
    {"name": "Asha",  "age": 20, "marks": 88},
    {"name": "Ravi",  "age": 22, "marks": 73},
    {"name": "Meera", "age": 21, "marks": 95},
]
students_dol = {
    "name":  ["Asha", "Ravi", "Meera"],
    "age":   [20, 22, 21],
    "marks": [88, 73, 95],
}

Both hold the same three students. students_lod is a list on the outside; students_dol is a dict on the outside. That single difference — what the outer container is — decides every access rule below.

The scenario matrix

The table below is a checklist you tick off, not just a summary. Read it left to right, one row at a time:

• The # column is a label (A–J) — a short name for a kind of problem, so we can point at it later ("this is Case F").
• Case class says in plain words what situation the row describes.
• What makes it tricky is the trap hiding in that situation — the reason it deserves its own example.
• Covered by tells you exactly which worked example below drives that trap into the ground.

How to use it: pick any row, cover the last column with your hand, and try to predict both the trap and how you'd handle it. Then read the matching example to check yourself. When every row feels obvious, you have covered every scenario this topic can throw.

Every numeric answer produced below is machine-checked in the verify block.

Example 1 — Cases A & B: the two coordinate systems

Steps.

1. students_lod[1] → the dict {"name": "Ravi", "age": 22, "marks": 73}. Why this step? The outer container is a list, so the only thing it understands is an integer position. Index 1 means "the second row" (counting from 0).
2. ... ["age"] → 22. Why this step? The value from step 1 is a dict, so the next bracket is a key lookup, not a position.
3. Now the DoL: students_dol["age"] → [20, 22, 21]. Why this step? The outer container is a dict, so the first bracket must be a key — it hands back the whole age column.
4. ... [1] → 22. Why this step? That column is a list, so we finish with an integer position.

Look at the figure below: the same yellow cell (row 1, age = 22) is reached by two different arrows — and the two index tokens appear in opposite order. That mirror is the whole idea.

Figure 1 — The 3×3 student table. The red arrow (LoD) enters from the top: first the integer [1] picks row 1, then ["age"] picks the column. The green arrow (DoL) enters from the bottom: first ["age"] picks the column, then [1] picks the row. Both arrows land on the same highlighted cell 22, and the yellow caption underneath reminds you the two index tokens swap order.

Example 2 — Case C: column math (average marks)

Steps.

1. DoL way: sum(students_dol["marks"]) → 88 + 73 + 95 = 256. Why this step? The column is already a flat list, so sum runs straight over it — no digging.
2. Divide: 256 / 3 = 85.333.... Why this step? Three students, so len(students_dol["marks"]) == 3.
3. LoD way: we must gather first — [s["marks"] for s in students_lod] → [88, 73, 95]. Why this step? In LoD the marks are scattered across separate row dicts. The comprehension visits each row and pulls its "marks" out into one list. Only then can we sum.
4. sum([88, 73, 95]) / 3 → same 85.333....

Verify: $\frac{88+73+95}{3}=\frac{256}{3}\approx 85.33$. The DoL path did less work (no gathering step) — that is exactly why column aggregates prefer DoL.

Example 3 — Case D: the transpose (LoD → DoL → LoD)

Steps.

1. LoD → DoL:

   dol = {k: [row[k] for row in students_lod] for k in students_lod[0]}

   Why this step? The outer comprehension walks the keys (name, age, marks), taken from the first row because all rows share keys. The inner comprehension walks every row collecting that key's value in row order. Result: {"name": [...], "age": [...], "marks": [...]}.
2. This yields dol["age"] == [20, 22, 21] — the age column, in order. Why this step? Sanity: the column must match the original ages top-to-bottom.
3. DoL → LoD (rotate back):

   keys = list(dol)                 # ["name","age","marks"]
   n = len(dol["name"])             # 3 rows
   lod2 = [{k: dol[k][i] for k in keys} for i in range(n)]

   Why this step? We loop the row index i from 0..n-1; for each i we build one dict by reading the i-th element of every column. This is data[c][i] → data[i][c] — the swap in reverse.
4. Compare: lod2 == students_lod?

Verify: the round trip returns the original list of dicts exactly — lod2 == students_lod is True. Rotating twice lands home, confirming LoD and DoL carry identical information, just rotated 90° — the "transpose" idea introduced in the parent note.

Example 4 — Case E: a missing key (ragged records)

Steps.

1. The outer loop takes keys from ragged[0] → ["name", "age"]. Why this step? It only sees the keys of the first row; it assumes all rows match.
2. Building the "age" column visits Meera's dict and evaluates row["age"]. Why this step? This is where the assumption breaks — Meera has no "age".
3. Result: KeyError: 'age'. The whole conversion dies. Why this step? A missing dict key with [...] is a hard error, not a silent None.
4. Fix with .get:

   dol = {k: [row.get(k) for row in ragged] for k in ragged[0]}

   Now row.get("age") returns None for Meera instead of exploding.

Verify: the fixed version gives dol["age"] == [20, 22, None]. The None is a visible flag saying "this cell was absent" — far safer than a crash.

Example 5 — Case F: the empty container (zero rows)

Steps.

1. DoL: sum(empty_dol["marks"]) → 0 (sum of nothing is 0, by definition). Why this step? sum over an empty list is a defined, safe 0.
2. len(empty_dol["marks"]) → 0. Why this step? Zero rows means zero-length columns.
3. 0 / 0 → ZeroDivisionError. Why this step? The average is undefined for zero items — the language refuses to guess.
4. Guard it:

   n = len(empty_dol["marks"])
   avg = sum(empty_dol["marks"]) / n if n else 0.0

   Why this step? We test if n (nonzero) before dividing and return a sensible default.
5. LoD trap variant: empty_lod[0] → IndexError. Why this step? There is no row 0 to read; always check if empty_lod: before indexing the first row.

Verify: with the guard, avg == 0.0 for the empty class — no crash. Empty-input handling is the single most-forgotten case in data code; always ask "what if there are zero rows?"

Example 6 — Case G: wrong index order (TypeError vs KeyError)

Steps.

1. students_lod["name"] — outer container is a list. Why this step? A list indexes by integer position only. It has no idea what the string "name" means as a position.
2. Result: TypeError: list indices must be integers or slices, not str. Why this step? Wrong type of index → TypeError (not KeyError). This is a precise tell: seeing TypeError here means "you fed a string to a list."
3. Now the mirror mistake: students_dol[0] on the dict. Why this step? A dict indexes by key. 0 is not a key in students_dol.
4. Result: KeyError: 0. Why this step? Right mechanism (key lookup), missing key → KeyError.
5. Fix: obey the outer container. LoD → integer first (students_lod[0]["name"]). DoL → key first (students_dol["name"][0]).

Verify: both fixed forms return "Asha". The type of exception is your diagnostic: TypeError = string into a list; KeyError = wrong key into a dict.

Example 7 — Case H: the shared-inner-list trap

Steps.

1. dict.fromkeys(cols, []) creates the default value list once and points every key at that same object. Why this step? fromkeys does not copy the default — all keys alias one list.
2. bad["name"].append("Asha") mutates that shared list. Why this step? Because bad["name"] and bad["marks"] are the same list, the append shows up under both keys.
3. Result: bad["marks"] == ["Asha"] too — a phantom value appeared in a column you never touched. Why this step? Aliasing (see Mutable vs Immutable): one object, two names.
4. Fix:

   good = {c: [] for c in cols}   # a FRESH list per key
   good["name"].append("Asha")

   Why this step? The dict comprehension runs [] once per key, creating independent lists.

Verify: with good, appending to "name" leaves good["marks"] == []; with bad it wrongly becomes ["Asha"]. Fresh-per-key is the only safe way to build a DoL from scratch.

Example 8 — Case I: real-world word problem

Steps.

1. Pick the shape: the data arrived as list of dicts (typical JSON array of objects). We filter rows, so LoD is the natural fit — each row is a self-contained record. Why this step? Filtering "which records qualify" is a row operation; LoD keeps each row whole.
2. Filter: passed = [s for s in students_lod if s["marks"] >= 80]. Why this step? The comprehension keeps only rows meeting the condition → Asha and Meera.
3. Gather ages: ages = [s["age"] for s in passed] → [20, 21]. Why this step? Now that rows are chosen, pull just the field we need to aggregate.
4. Average: sum(ages) / len(ages) → 41 / 2 = 20.5. Why this step? Two passing students; guard len(ages) if the filter could be empty (Case F!).

Verify: average passing age $=\frac{20+21}{2}=20.5$ years (units: years, since we averaged ages). Filter-then-aggregate on LoD is the everyday API workflow — and a natural feeder into a Pandas DataFrame if the data grows.

Example 9 — Case J: exam twist (mutate while iterating)

Steps.

1. Trace the naive loop. It walks by an internal position counter starting at 0. At counter 0 it sees Asha (20 < 21) and removes her; now every later element shifts left by one, so Ravi is at position 0, Meera at 1, Kiran at 2. Why this step? Removing during iteration desynchronises the loop's counter from the (now shorter) list.
2. The loop advances the counter to 1 — but after the shift, position 1 holds Meera (21), not Kiran. Ravi at position 0 was jumped over entirely. Why this step? Because indices moved under the loop's feet, the element that slid into the just-vacated slot is never examined.
3. The loop reaches the end without ever testing Kiran (19), so Kiran survives even though he should be deleted — a silent wrong answer, not a crash. Why this step? This is the classic "mutate-while-iterating" bug of Loops and Iteration; the traversal and the mutation fight each other, giving effectively undefined results.
4. Fix — rebuild, don't mutate:

   people = [p for p in people if p["age"] >= 21]

   Why this step? We build a new list from a fresh, complete pass, so the original is never disturbed mid-iteration. Every element is tested exactly once.

Verify: the comprehension yields exactly ["Ravi", "Meera"] (both age >= 21), i.e. 2 survivors. The rebuild is correct where the in-place removal silently kept Kiran (19) — the whole point of Case J.

Connections

• Parent topic
• Lists — the integer-indexed outer container of LoD
• Dictionaries — the key-indexed container; .get saves Example 4
• List Comprehensions — the gather / filter / transpose engine
• JSON and APIs — source of the Example 8 list-of-dicts
• Pandas DataFrame — where column math (Example 2) scales up
• Loops and Iteration — the mutate-while-iterating trap (Example 9)
• Mutable vs Immutable — the shared-list aliasing bug (Example 7)

Concept Map