List - dict comprehensions and generators: Worked examples

This is a parent topic deep dive. Here we don't teach the syntax from scratch — the parent did that. Instead we hunt down every kind of situation comprehensions and generators can throw at you, and we work each one to the ground. If you have not yet met the words iterable, yield, or lazy evaluation, read the parent note first, then come back.

The scenario matrix

Every worked example below is tagged with a cell code (e.g. [C3]) so you can see the box being ticked.

Cell	Case class	The tricky part it stresses
C1	Plain map (transform only)	Baseline: expression per item
C2	Map + filter (`if` clause)	Order: filter then transform
C3	Two iterables via `zip` → dict	Pairing keys with values
C4	Nested / flatten	Left-to-right reading of nested `for`
C5	Empty / degenerate input	Empty iterable → empty result, no crash
C6	Generator exhaustion	Consumed-once behaviour
C7	Infinite / limiting stream	Lazy `yield` lets $n \to \infty$ work
C8	Memory word-problem (real ML)	List vs generator on a huge file
C9	Conditional expression (`if…else` in the expression)	Different placement of `if`
C10	Exam twist — side-effect trap	Purity, iterator invalidation

We now walk C1 → C10. Guess each answer before reading the steps.

Worked example C1 — Plain map (transform only)

Statement: Build a list of the cubes of $0$ through $5$ .

Forecast: How many items? What is the last one? Guess before scrolling.

Choose the tool. Why this step? We want one output per input, no dropping — that is exactly a map, so a bare comprehension [expr for x in it] (no if) is the minimal fit.
Write it.
```
cubes = [x**3 for x in range(6)]
```
Why this step? range(6) yields $0, 1, 2, 3, 4, 5$ — remember range(6) stops before $6$ , so there are $6$ items, not $7$ . The expression x**3 runs once per item.
Result: [0, 1, 8, 27, 64, 125].

Verify: Count = $6$ ✓ (matches len(range(6))). Last item $= 5^{3} = 125$ ✓. Cubes grow, so the list is sorted ascending — sanity holds.

Worked example C2 — Map

and filter Statement: From $0$ to $9$ , keep only the numbers divisible by $3$ , and store their squares.

Forecast: Which numbers survive the filter? What do their squares look like?

Split the job into filter + transform. Why this step? The parent's rule is iterate → filter → transform → collect. The condition decides who enters; the expression decides what they become.
Write it.
```
out = [x**2 for x in range(10) if x % 3 == 0]
```
Why this step? x % 3 == 0 is True for $x \in {0, 3, 6, 9}$ . % is the remainder operator — " $x$ divided by $3$ leaves nothing over". Only those four reach x**2.
Result: [0, 9, 36, 81].

Verify: $0^{2}, 3^{2}, 6^{2}, 9^{2} = 0, 9, 36, 81$ ✓. Four survivors ✓ ( $10/3 \approx 3.3$ , rounded up counting $0$ gives $4$ ). No non-multiple of $3$ appears ✓.

Worked example C3 — Two iterables → dict (

zip) Statement: Given names = ['ann','bob','cy'] and ages = [30, 25, 41], build {'ann':30, 'bob':25, 'cy':41}.

Forecast: What happens if the two lists had different lengths? Hold that thought.

Pair them up. Why this step? zip(names, ages) walks both lists in lockstep, producing tuples ('ann',30), ('bob',25), ('cy',41). This is the standard "line up two columns" move — see 1.4.01-Basic-Python-syntaxand-data-structures for tuples.
Unpack and build.
```
d = {k: v for k, v in zip(names, ages)}
```
Why this step? k, v unpacks each tuple; {k: v ...} is the dict form (colon separates key from value).
Result: {'ann': 30, 'bob': 25, 'cy': 41}.

Edge note (degenerate): if ages were [30, 25] (shorter), zip stops at the shorter one — 'cy' would silently vanish. That is a classic quiet bug.

Verify: d['bob'] $= 25$ ✓, and len(d) $= 3$ ✓ (three key–value pairs).

Worked example C4 — Nested / flatten

Statement: Flatten grid = [[1,2,3],[4,5],[6]] into one list.

Forecast: The rows have different lengths. Does that break flattening? How many items total?

Read the nested for left-to-right. Why this step? The rule from the parent: the leftmost for is the outer loop, the next for is the inner loop — exactly the order you'd write two stacked for statements.
Write it.
```
flat = [item for row in grid for item in row]
```
Why this step? for row in grid walks the three sub-lists; for item in row walks inside each. Ragged rows are fine — the inner loop simply runs a different number of times per row.
Result: [1, 2, 3, 4, 5, 6].

Verify: Total items $= 3 + 2 + 1 = 6$ ✓ (sum of row lengths). Order preserved row-by-row ✓.

Worked example C5 — Empty / degenerate input

Statement: What does [x**2 for x in []] give? And {k: v for k, v in zip([], [])}? And a filter that no one passes: [x for x in range(5) if x > 100]?

Forecast: Crash? None? Something empty?

Empty iterable. Why this step? A comprehension is "run the loop body zero times if there is nothing to loop over". Zero runs → empty container, never an error.
```
a = [x**2 for x in []]        # []
b = {k: v for k, v in zip([], [])}  # {}
```
Filter that nobody passes. Why this step? Every item is tested and rejected, so again the body collects nothing.
```
c = [x for x in range(5) if x > 100]  # []
```
Result: a == [], b == {}, c == [].

Verify: len(a) == 0, len(b) == 0, len(c) == 0 — all True ✓.

Worked example C6 — Generator exhaustion (consumed once)

Statement: g = (x for x in range(4)). What does list(g) give the first time, and the second time?

Forecast: Same list twice? Or does something change?

First drain. Why this step? A generator holds only its current position, not the data. list(g) walks it to the end, moving that position marker to "finished".
```
first  = list(g)   # [0, 1, 2, 3]
```
Second drain. Why this step? The marker is already at the end. There is nothing left to yield, so iteration stops immediately.
```
second = list(g)   # []
```
Result: first == [0,1,2,3], second == [].

Verify: first == [0,1,2,3] ✓ and second == [] ✓.

Worked example C7 — Infinite / limiting stream

Statement: Write a generator of all powers of two ( $1, 2, 4, 8, \dots$ forever) and safely take the first $6$ .

Forecast: Can a loop with no end condition ever finish? Why doesn't this hang?

An endless yield loop. Why this step? Because a generator is lazy, while True is fine — it only ever computes the value someone asks for. Nothing is precomputed, so there is no "store infinity" problem.
```
def powers_of_two():
    p = 1
    while True:
        yield p
        p *= 2
```
Take exactly six. Why this step? We stop pulling after $6$ values; the generator pauses forever after the sixth yield, never reaching a seventh.
```
g = powers_of_two()
out = [next(g) for _ in range(6)]
```
next(g) asks for one value at a time. _ means "loop variable I don't care about".
Result: [1, 2, 4, 8, 16, 32].

Why this is the whole point: replacing while True with a list would try to store an infinite sequence — instant crash. Laziness turns "infinite" into "on demand". This is the same mechanism behind streaming batches in 1.5.01-Batch-processing-and-mini-batches.

Verify: The $k$ -th item is $2^{k}$ starting at $k = 0$ : $2^{0} .. 2^{5} = 1, 2, 4, 8, 16, 32$ ✓. Sum $= 63 = 2^{6} - 1$ ✓.

Worked example C8 — Memory word problem (real ML)

Statement: A CSV ratings.csv has $50, 000, 000$ lines. You must compute the average rating. Each parsed record costs $\approx 200$ bytes if stored. Compare storing all vs streaming.

Forecast: Roughly how many gigabytes does the list version want? Does the streaming version care about $n$ at all?

The list way (bad here). Why this step? A list holds every record at once, so memory $\approx n \times item_size$ . $List RAM \approx 50, 000, 000 \times 200 bytes = 1.0 \times 1 0^{10} bytes \approx 10 GB .$
The generator way (good here). Why this step? A generator holds only its iterator state, which is $O (1)$ — a few hundred bytes regardless of $n$ . We keep just a running sum and count.
```
total, count = 0, 0
for r in (parse(line) for line in open('ratings.csv')):
    total += r
    count += 1
avg = total / count
```
See 1.4.04-File-IO-and-data-loading for why open(...) is itself lazy line-by-line.
Result: streaming uses $\sim 1 MB$ instead of $\sim 10 GB$ — a factor of about $1 0^{4}$ .

Verify: $50, 000, 000 \times 200 = 1.0 \times 1 0^{10}$ bytes $= 10$ GB (using $1 0^{9}$ bytes/GB) ✓. Memory ratio $10 GB /1 MB = 1 0^{10} /1 0^{6} = 1 0^{4}$ ✓.

Worked example C9 — Conditional

expression (if…else inside the value) Statement: For $0$ to $6$ , output "even" or "odd" for each number.

Forecast: The if here does not filter — it chooses the value. Where must it sit?

Distinguish the two if placements. Why this step? This is the #1 confusion:
- [expr for x in it if cond] → if at the end = filter (drops items).
- [a if cond else b for x in it] → if…else at the front = ternary, part of the expression (keeps every item, just picks its value).
Write the ternary form.
```
tags = ["even" if x % 2 == 0 else "odd" for x in range(7)]
```
Why this step? Every x produces one output, so no filtering — the count stays $7$ .
Result: ['even','odd','even','odd','even','odd','even'].

Verify: Length $= 7$ ✓. Positions $0, 2, 4, 6$ are "even", positions $1, 3, 5$ are "odd" ✓.

Worked example C10 — Exam twist: the side-effect trap

Statement: A student writes nums = [x for x in nums if not nums.remove(x)] to "keep the even numbers" from nums = [1,2,3,4]. Explain why it misbehaves and give the correct filter.

Forecast: Will it delete cleanly, skip items, or crash? Predict the leftover list.

Spot the impurity. Why this step? A comprehension must be a pure expression — it reads the iterable, it must not mutate it mid-flight. nums.remove(x) deletes from the very list being iterated, shifting indices and causing skipped elements (iterator invalidation). The result is garbage that looks plausible.
Write the correct, pure version. Why this step? Build a new list from a clean condition; never remove during iteration.
```
nums = [1, 2, 3, 4]
evens = [x for x in nums if x % 2 == 0]   # [2, 4]
```
If you truly need in-place replacement, do it after computing:
```
nums[:] = [x for x in nums if x % 2 == 0]  # nums becomes [2, 4]
```
Why this step? nums[:] = ... rebinds the contents while keeping the original object — safe because the right side is fully built before assignment overwrites anything.
Result: evens == [2, 4]; the buggy side-effect version is unreliable and must be avoided.

Verify: Filtering evens of $[1, 2, 3, 4]$ gives $[2, 4]$ ✓. Sum of result $= 6$ ✓.

Recall Self-test: name the cell for each snippet

[len(w) for w in words] hits which cell? ::: C1 (plain map) (x for x in range(9)); list(that); list(that) demonstrates which cell? ::: C6 (exhaustion) ["hi" if x else "lo" for x in flags] is which cell? ::: C9 (ternary in the expression) Reading [c for row in grid for c in row] left-to-right is which cell? ::: C4 (nested flatten) Streaming a 10 GB file with (...) instead of [...] is which cell? ::: C8 (memory word problem)

Recall One-line summary

Front if…else chooses a value; back if filters; zip pairs; nested for reads outer→inner; generators are single-use lazy straws; empty inputs give empty outputs, never crashes.