Question bank — List - dict comprehensions and generators

False. Both produce the same full list in memory, so peak memory is essentially identical; the comprehension is just faster and shorter, not lighter.

True — but only because it never builds the full collection. It stores just the cursor state, so its saving is the whole point, not a side effect.

False. Brackets [] build a list (all values now); parentheses () build a generator (values on demand). They print differently and behave differently on a second pass.

False. A generator has no stored contents to count — it would have to run to the end to know its length, which also consumes it. Only materialized collections like lists support len().

True. The list is not consumed; each for loop makes a fresh cursor from the start. This is exactly what a generator cannot promise.

True. If two items map to the same key, the later one overwrites the earlier — so duplicate keys silently shrink the result.

True. The keys are 1, -1, and 2 — all distinct — so you get three entries {1: 1, -1: 1, 2: 4}. Note 1 and -1 map to the same value 1, but distinct keys never collide, so nothing is lost.

False. It uses yield to hand out values; a bare return just ends iteration early. Mixing them, return stops the generator without producing a final value.

False. Set comprehensions use {expr for ...}; generator expressions use (expr for ...). Braces mean set (or dict, with a colon), never generator.

Two bugs. list.remove(x) returns None, so not None is always True — the filter keeps everything the loop reaches. Worse, remove deletes the current item and shifts every later element one slot left, but the cursor still advances to the next index — so it now lands on what used to be two slots away, silently skipping the element that slid into the gap. Never mutate what you iterate; build a new list: [x for x in my_list if keep(x)].

list(gen) consumed the generator, so sum(gen) iterates an empty, exhausted cursor and returns 0. Rebuild the generator or use a list if you need two passes.

train consumes the generator, leaving test nothing. For multiple passes over the same large data, either re-create the generator each time or accept the memory cost of a list.

The brackets force a 100-million-element list into memory before summing. Drop the brackets — sum(x**2 for x in range(10**8)) streams one value at a time in $O(1)$ (constant) space.

This is a nested loop, pairing every key with every value and keeping only the last v — it does not zip them. Use {k: v for k, v in zip(keys, values)}.

The loop order is reversed — row is used before it is defined. Nested comprehensions read left-to-right like nested loops: [item for row in matrix for item in row].

The return 5 does not yield 5; it ends the generator (and sets a StopIteration value nobody usually reads). Result is [1].

Because the list-building loop runs in optimized C internals rather than repeated Python-level .append() attribute lookups and calls, so Python's interpreter has less per-iteration overhead.

It never holds all the data at once — it reads, transforms, and hands back one record, then forgets it. Only the current item plus the cursor's tiny state live in memory. See file IO.

They compute nothing until a value is actually requested. Wrapping generators (like evens(squares(n))) builds a pipeline that only advances one step per requested item — perfect for mini-batching.

The comprehension reads as filter-then-transform: each item is tested, and only survivors reach the expression. So [x**2 for x in r if x % 2 == 0] never squares odd numbers.

Let $k$ be the number of times you loop over the whole collection (one pass means $k=1$; five training epochs means $k=5$). When $k=1$ a generator avoids storing everything for no benefit. When $k>1$ over small data, a list computes each item once and re-serves it cheaply across all $k$ passes, avoiding recomputation.

On first access it computes only one value instead of the whole collection. Over a full pass it recomputes each item live, whereas a pre-built list just reads finished values sitting in cache.

A generator is defined by that protocol — next() resumes it, StopIteration ends it. Understanding the protocol explains exactly why a consumed generator yields nothing on a second loop.

An empty list []. An empty iterable yields nothing, but this is perfectly valid — no error, just zero items.

An empty sequence. If the loop inside never reaches a yield (e.g. fibonacci(0)), iterating it gives nothing, cleanly.

You get an empty list, dict, or generator — never an error. Filtering to nothing is a legal, common result.

Two — keys can only be 0 or 1, and each later collision overwrites, so you keep {0: 4, 1: 3}.

Yes — e.g. [sum(y for y in row) for row in matrix]. The inner generator stays lazy; the outer comprehension materializes the per-row sums.

It raises StopIteration (which a for loop silently catches to stop). The generator is done and will never produce more values.

No — it produces an empty dict {}. Like all comprehensions, zero iterations is a valid, silent outcome.