Exercises — Generator expressions — memory efficiency

Only b is a generator expression.

• a uses square brackets [] → a list.
• b uses round brackets () → a generator (the one lazy object here).
• c uses curly brackets {} → a set (eager, all built now).
• d contains a generator expression, but list(...) immediately drains it into a list. The final object d is a list.

Rule: the punctuation around the comprehension decides the type. See List comprehensions for the eager [] cousin.

<class 'generator'>. A common wrong guess is tuple, because round brackets usually make tuples. But a tuple has no for inside — (1, 2, 3) is a tuple, while (n for n in range(5)) is a generator. The presence of for ... in ... inside the parentheses is what flips it.

0, then 10, then 20. Each next(g) pulls one value, advances the internal position, and forgets the previous one — exactly the single-box picture at the top. A fourth next(g) would raise StopIteration, because there are only three values to give.

9. The filter if x % 2 == 1 keeps the odd numbers from 1..5: that is 1, 3, 5. Their sum is $1+3+5=9$. sum never sees a list — it receives each odd number one at a time and adds it to a running total.

biggest = max(len(w) for w in ["hi", "world", "ok"])

When a generator expression is the only argument to a call, Python lets you drop the inner parentheses. Answer value: the word lengths are 2, 5, 2, so max returns 5.

Same result, very different peak memory.

• A first builds a list of one million integers, then sums it. Peak extra memory is $O(n)$ — it holds all $n$ items simultaneously (~8 MB+ of pointers plus the ints).
• B streams one square at a time into sum; only one value exists at any instant, so peak extra memory is $O(1)$.

Both compute the same total, so the time is comparable; the space is the whole point. See Big-O space complexity.

Line 1: [0, 2]. Line 2: []. The first list(g) walks the generator all the way to the end, collecting the even numbers 0, 2. That single pass exhausts the generator. The second list(g) finds nothing left to yield, so it returns an empty list. A generator does not rewind. This is the exhaustion behaviour from the parent note — see also Iterators and the iterator protocol.

Version 1 reads less.

• Version 1 uses a generator with next. It stops the moment it finds the first "ERROR" line and reads no further. This is Lazy evaluation in action.
• Version 2 builds a full list of every error line (scanning the entire file), then throws all but [0] away. It does maximum work to keep one item.

Same answer, but Version 2 may read millions of lines Version 1 never touches.

[0, 1, 4, 9, 16]. squares would yield 0, 1, 4, 9, 16, 25. The second generator small pulls from squares one value at a time and passes through only those < 20. 25 is dropped. Crucially, no full list of squares is ever built — values flow one-by-one through the whole pipeline. This is composition of lazy iterators.

The generator is exhausted by the first list(evens). If you genuinely need the data twice, materialise it once into a list:

evens = [n for n in range(10) if n % 2 == 0]   # a real list, reusable
print(evens)          # [0, 2, 4, 6, 8]
print(sum(evens))     # 20

Now evens is a list, so both passes see the full data. Sum: $0+2+4+6+8=20$. Rule of thumb: need it once and lazily → generator. Need it many times → list.

lengths = (len(w) for w in words if len(w) > 2)
print(list(lengths))   # [3, 3, 8]

Words longer than 2 letters: "cat" (3), "dog" (3), "elephant" (8). "ox" (2) is filtered out. Result: [3, 3, 8].

• list(x for x in range(0)) → []. range(0) yields nothing, so the generator is empty from birth.
• sum(x for x in []) → 0. Summing zero numbers gives the additive identity 0.
• next((x for x in []), "none") → "none". When a generator is empty, next with a default returns that default instead of raising StopIteration.

Edge cases matter: an empty generator is legal and common — always safe, never an error unless you call next on it without a default.

TypeError: 'generator' object is not subscriptable. A generator has no stored elements to index into — there is no "slot 0" sitting in memory. To get the first item use next(g); to get an arbitrary position you must iterate up to it (or convert to a list first, paying the memory cost).

[0, 100, 200]. This is the deep one. The generator does not compute anything at creation time — it is lazy. It only runs its body when list(g) iterates it, and by then m is 100. So it uses the current value of the free variable m, not the value at the moment the generator was written. Because iteration is deferred, the environment it reads is also deferred. Contrast: a list comprehension [x * m for x in range(3)] would evaluate immediately with m == 2, giving [0, 2, 4].

Output order:

built generator
made 0
first: 0

make runs zero times when the generator is built — creation does no work. It runs once on the first next(g), printing made 0, then yielding 0. The values made 1 / made 2 never appear because we never asked for them. This is the printer-prints-on-demand model made visible. See Lazy evaluation and Generator functions and yield.

A generator is a recipe that runs on demand: it holds no data, does no work, and reads its variables only when you pull a value. That is why it costs $O(1)$ memory, why it exhausts after one pass, why it can't be indexed, why empty inputs are harmless, and why a variable changed after building it still affects the output. All five behaviours are the same fact — "compute later, one at a time" — seen from different angles.