Built-in functions — map, filter, zip, enumerate, sorted, reversed, min, max, sum, any, all: Worked examples

This page drills the parent topic until no case can surprise you. We first lay out a scenario matrix — every kind of situation these 11 functions can be thrown into — then work examples that hit every cell.

Before we start, one word we will lean on: an iterable is anything you can walk item-by-item (a list, a string, a range). An iterator is a one-shot walker over an iterable — it hands you items one at a time and, once emptied, stays empty (see Iterators and generators). Whenever a function below is called "lazy", it hands back an iterator, so we wrap it in list(...) to force the items into view.

Two more small tools we will meet along the way (both explained in full when they first appear):

The ==star *== in front of a list "spreads" it into separate arguments. Think of *[1,2,3] as pouring the box out so a function receives 1, 2, 3 as three separate arguments rather than one list. (Example 8 builds this visually before using it.)
A generator expression looks like a list comprehension but with round brackets: (x for x in xs if cond). It is lazy — it produces items one at a time on demand instead of building a whole list first (contrast with List comprehensions, which build the full list eagerly). (Example 6 explains this before using it.)

The scenario matrix

Every row is a case class — a distinct situation that behaves differently. The map below is our checklist: each leaf is one cell, and the example that fills it is named on the leaf. When every leaf is ticked, no scenario is left uncovered.

Cell	Case class	What makes it tricky	Covered by
A	Empty input	Crash, or sensible default?	Ex 1
B	Single element	Reducers with one item	Ex 1
C	Unequal-length iterables (`zip`/`map`)	Which one decides when to stop?	Ex 2
D	Truthiness edge cases (`filter(None,…)`)	`0`, `''`, `[]`, `None` are all falsy	Ex 3
E	Vacuous truth (`all([])`, `any([])`)	Empty logic defaults	Ex 3
F	`key=` for order vs. `filter` for removal	The classic confusion	Ex 4
G	Stability + ties in `sorted`	Equal keys keep original order	Ex 4
H	Consuming a lazy iterator twice	Second pass sees nothing	Ex 5
I	Negative numbers / signs in a reduce	`min`/`max`/`sum` across mixed signs	Ex 6
J	Wrong `start` / type mismatch (`sum` of strings)	Silent-looking bug that raises	Ex 6
K	Real-world word problem (chaining)	Combining tools into a pipeline	Ex 7
L	Exam-style twist (`zip(*…)` unzip, short-circuit)	Non-obvious mechanics	Ex 8
M	`reversed` vs `sorted(…, reverse=True)`	Back-to-front walk vs. re-ordering	Ex 9

Example 1 — Empty & single-element inputs (cells A, B)

Worked example The degenerate reducers

Predict the output of each line before reading on:

sum([])            # ?
any([])            # ?
all([])            # ?
max([7])           # ?
max([], default=0) # ?

Steps.

sum([]) → 0. Why this step? sum starts from an accumulator called start, and its default is 0. Adding nothing to 0 leaves 0. Nothing to add ⇒ you get the identity of +.
any([]) → False. Why this step? any is a chain of ORs. With no terms, the answer is the identity of OR, which is False (see Truthiness in Python).
all([]) → True. Why this step? all is a chain of ANDs. No terms ⇒ identity of AND ⇒ True. This is vacuous truth — "every item is truthy" is trivially satisfied when there are no items to violate it.
max([7]) → 7. Why this step? One element is trivially the largest of one element. This is the single-element case: min and max collapse a one-item list to that item.
max([]) raises ValueError — there is no "largest of nothing". To ask safely, pass default: max([], default=0) → 0. Why this step? Unlike sum, max/min have no natural identity element (what's the "largest possible number"?), so Python forces you to name a fallback.

Example 2 — Unequal-length iterables (cell C)

Worked example Who decides the stopping point?

a = [1, 2, 3, 4, 5]
b = [10, 20, 30]
zipped = list(zip(a, b))
mapped = list(map(lambda x, y: x + y, a, b))

Forecast: how many pairs does zip make — 3 or 5? What does the leftover [4, 5] become?

Steps.

zip pairs by position: (1,10), (2,20), (3,30). Why this step? zip walks all inputs in lockstep and stops the instant the shortest runs dry. Once b is exhausted after 3 items, there is no partner for a's 4 and 5, so they are silently dropped.
map with two iterables behaves the same way: 1+10, 2+20, 3+30 → [11, 22, 33]. Why this step? Multi-iterable map feeds one item from each input into f; like zip, it halts at the shortest. So 4 and 5 never reach the lambda.

The figure below makes the truncation visible: the top row is a, the bottom row is b, the yellow arrows show which positions get paired, and the pink 4 and 5 at the far right have no partner below them, so they fall out entirely.

Figure — Built-in functions — map, filter, zip, enumerate, sorted, reversed, min, max, sum, any, all

Notice in the figure that only three yellow arrows are drawn — one per surviving pair — confirming zip produced a length-3 result, not length-5.

Example 3 — Truthiness & vacuous logic (cells D, E)

Worked example Falsy hunting

data = [0, '', 'hi', [], [1], None, 3]
kept   = list(filter(None, data))
got1   = any(data)
gotall = all(data)

Forecast: which items survive filter(None, …)? Will any and all be True or False?

Steps.

filter(None, data) keeps each item that is truthy. The falsy values in Python are 0, '', [], None (and False, 0.0). So they get dropped, leaving ['hi', [1], 3]. Why this step? Passing None as the predicate means "use the item's own truthiness as the test" — a shorthand for filter(lambda x: x, data).
any(data) → True. Why this step? any returns True as soon as it meets one truthy item. 'hi' (index 2) is truthy, so it short-circuits there and returns True.
all(data) → False. Why this step? all returns False at the first falsy item. The very first item 0 is falsy, so all stops immediately and returns False.

In the figure below, each item sits in a box coloured pink for falsy and blue for truthy. The blue boxes ('hi', [1], 3) are exactly what filter(None,…) keeps. The pointer from any lands on the first blue box (index 2 — where it stops and returns True); the pointer from all lands on the first pink box (index 0 — where it stops and returns False).

Recall Why the empty defaults are consistent

On an empty list, any never finds a truthy item ⇒ False (cell E); all never finds a falsy item ⇒ True. Same rules, no items to trip them.

Example 4 — `key` orders, `filter` removes; and ties (cells F, G)

Worked example "Sort by even-ness" — the trap

nums = [5, 2, 8, 1, 4, 7]
wrong = sorted(nums, key=lambda x: x % 2 == 0)
right = list(filter(lambda x: x % 2 == 0, nums))

Forecast: does wrong throw away the odd numbers? What order do the evens end up in?

Steps.

key=lambda x: x % 2 == 0 maps each item to True/False (1/0). sorted orders by that key: all False (odd) items first, then all True (even) items. Why this step? key never removes anything — it only computes a sort value. So wrong still contains all six numbers, just reordered into odds-then-evens.
Within each key-group, stability preserves the original relative order. Odds appear as they did (5, 1, 7), then evens (2, 8, 4). So wrong == [5, 1, 7, 2, 8, 4]. Why this step? Python's sort is stable: items with equal keys keep their input order. Every odd shares key False, every even shares True, so ties = original order.
To actually drop the odds, use filter: right == [2, 8, 4]. Why this step? filter keeps items where the predicate is truthy and discards the rest — that is the removal tool, not key.

Example 5 — A lazy iterator is single-use (cell H)

Steps.

map(...) builds a lazy iterator — it computes nothing yet. Why this step? Laziness means work happens only when items are pulled. Right now squares is a promise, not a list.
list(squares) pulls every item: first == [1, 4, 9]. This drains the iterator to empty. Why this step? An iterator has an internal position; forcing it to the end leaves the position past the last item, with nothing behind it.
list(squares) again finds nothing left: second == []. Why this step? Iterators do not rewind. The second list(...) walks an already-exhausted stream, so it collects an empty list.

Example 6 — Signs in reducers, and `sum` type mismatch (cells I, J)

Before this example uses a generator expression, let's earn the notation. A generator expression is written (x for x in xs if cond) — round brackets, one item produced on demand. It is the lazy cousin of a list comprehension [x for x in xs if cond] (square brackets, whole list built at once). We feed a generator expression to max here so no throwaway list is built — max simply pulls items one at a time and remembers the largest. See Iterators and generators for the lazy machinery.

Worked example Mixed signs and a wrong start

temps = [-4, -9, 3, 0, -1, 6]
lo   = min(temps)
hi   = max(temps)
tot  = sum(temps)
hottest_below0 = max(t for t in temps if t < 0)   # generator expression
broken = sum(['a', 'b', 'c'])                      # what happens?

Forecast: predict lo, hi, tot. Then decide: does the last line return 'abc' or crash?

Steps.

min(temps) scans for the most-negative value: -9. Why this step? min compares numerically; more negative = smaller. Signs are handled by ordinary <, no special case needed.
max(temps) → 6; sum(temps) → -4 + -9 + 3 + 0 + -1 + 6 = -5. Why this step? sum folds + across the list starting from 0; negatives just subtract. This is the mixed-sign case working out to a negative total.
max(t for t in temps if t < 0) → -1. Why this step? The generator expression (t for t in temps if t < 0) lazily yields only the negatives (-4, -9, -1); max pulls them one by one and keeps the largest, which among negatives is the one closest to zero.
sum(['a','b','c']) raises TypeError. Why this step? sum begins at start=0 (an int), then computes 0 + 'a' — you can't add a number to a string. For strings use ''.join([...]), which gives 'abc'.

Example 7 — Real-world pipeline (cell K)

Worked example Class scoreboard

You have parallel lists of names and raw marks. Build a leaderboard: pass = mark ≥ 40, ranked highest-first, tagged with 1-based rank.

names = ['Ana', 'Ben', 'Cy', 'Deb', 'Eli']
marks = [72, 35, 58, 40, 39]

Forecast: who appears, in what order, and what rank does the top scorer get?

Steps.

Pair names with marks: zip(names, marks) → ('Ana',72), ('Ben',35), …. Why this step? The two lists carry one student's data across two places; zip stitches them into single records so we can sort them as units.
Keep passers: filter(lambda p: p[1] >= 40, pairs) keeps Ana(72), Cy(58), Deb(40). Why this step? Removal is filter's job (never key). Ben(35) and Eli(39) fall below 40 and are dropped.
Rank highest-first: sorted(passers, key=lambda p: p[1], reverse=True) → Ana(72), Cy(58), Deb(40). Why this step? key picks the sort field (the mark, index 1); reverse=True flips to descending so the top scorer leads.
Attach rank: enumerate(ranked, start=1) → (1,('Ana',72)), (2,('Cy',58)), (3,('Deb',40)). Why this step? enumerate supplies a 1-based counter alongside each record — cleaner than range(len(...)), which is error-prone. See how this chains into List comprehensions and Lambda functions.

board = list(enumerate(
    sorted(filter(lambda p: p[1] >= 40, zip(names, marks)),
           key=lambda p: p[1], reverse=True),
    start=1))
# [(1,('Ana',72)), (2,('Cy',58)), (3,('Deb',40))]

Example 8 — Exam twist: unzip with `*`, and true short-circuit (cell L)

First we earn the ==star *==. When you put * in front of a list inside a function call, Python "spreads" the list into separate positional arguments. So zip(*[(1,'a'),(2,'b'),(3,'c')]) is exactly zip((1,'a'), (2,'b'), (3,'c')) — three separate arguments, not one list argument. The figure shows this pouring-out: the boxed list on the left is emptied into three loose tuples on the right, which then feed zip.

Worked example The star and the lazy AND

pairs = [(1, 'a'), (2, 'b'), (3, 'c')]
nums, letters = zip(*pairs)              # unzip
 
def positive(x):
    print('checked', x)                  # side effect: proves what got evaluated
    return x > 0
 
safe = all(positive(x) for x in [4, 5, -1])   # generator -> lazy, short-circuits

Forecast: what are nums and letters? And when all runs over the generator, how many values get printed before it stops?

Steps.

*pairs spreads the list into separate arguments, so zip(*pairs) is zip((1,'a'), (2,'b'), (3,'c')) (as the figure showed). Why this step? zip now treats each tuple as an input and pairs them column-wise: first elements together, second elements together. This inverts the original zipping.
Result: nums == (1, 2, 3), letters == ('a', 'b', 'c'). Why this step? Column 0 is all the numbers, column 1 is all the letters — the two columns are exactly the originals we zipped from.
True short-circuit. all(positive(x) for x in [4, 5, -1]) receives a generator expression (lazy), so all pulls values one at a time. positive(4) → True, positive(5) → True, positive(-1) → False; at that first False, all stops and returns False. Crucially, all three were truthy-tested here, but the short-circuit means all never pulls a fourth item even if the generator could produce more. Why this step? Because the generator is lazy, positive runs only when all asks. Compare this with the broken attempt below, where an eager list defeats short-circuiting entirely.

Common mistake Why a pre-built list defeats short-circuiting

all([4 > 0, 5 > 0, 1/0 > 0])   # ZeroDivisionError BEFORE all() ever runs

Why it feels right: you expect all to stop early and skip 1/0. Reality: the list literal [..., 1/0 > 0] is fully evaluated first, so 1/0 explodes before all is even called. Short-circuiting can only help when items are produced lazily — pass a generator all(cond() for cond in checks), not a list.

Example 9 — `reversed` vs `sorted(…, reverse=True)` (cell M)

Worked example Back-to-front is NOT the same as descending

xs = [3, 1, 2]
walk_back  = list(reversed(xs))
descending = sorted(xs, reverse=True)
word       = ''.join(reversed('chalk'))
gen_once   = reversed(xs)     # is this reusable?

Forecast: will walk_back equal descending? What string does word produce?

Steps.

reversed(xs) walks the existing order from the last item to the first: xs is [3, 1, 2], so back-to-front is [2, 1, 3]. Why this step? reversed does no ordering — it only flips the direction of travel. It needs a sequence with a known length (list, tuple, range, str) so it can start from the end and step backwards.
sorted(xs, reverse=True) first sorts ascending (1, 2, 3) then flips to descending: [3, 2, 1]. Why this step? reverse=True reverses the sorted result, not the original. This is why walk_back ([2,1,3]) and descending ([3,2,1]) differ — one reflects input order, the other reflects magnitude.
''.join(reversed('chalk')) walks the characters back-to-front (k, l, a, h, c) and joins them: 'klahc'. Why this step? A string is a sequence, so reversed iterates its characters end-to-start; ''.join(...) glues that iterator back into a string.
reversed(xs) returns a lazy, single-use iterator — just like map. Consume it once (list(...)) or it empties out, exactly the trap from Example 5. Why this step? reversed shares the one-shot nature of the other lazy tools, so the same "materialise once" advice applies.

The figure contrasts the two operations on [3, 1, 2]: the top track shows reversed simply reading the same boxes right-to-left (2, 1, 3); the bottom track first sorts into 1, 2, 3 and then flips to 3, 2, 1. Different results from different intents.

Recall One-line summary of the matrix

Empty ⇒ know each default (sum→0, any→False, all→True, min/max crash unless you pass default=). zip/map stop at the shortest input. filter(None,…) drops falsy values (0, '', [], None). key only orders, filter removes; sort is stable so ties keep input order. Lazy iterators (map, filter, zip, enumerate, reversed) run once — materialise with list(...) to reuse. sum of strings is a TypeError (use ''.join). *pairs spreads a list into separate arguments, so zip(*pairs) unzips column-wise. Generator expressions (x for x in xs) are lazy, which is what lets any/all short-circuit. reversed mirrors input order (back-to-front), while sorted(..., reverse=True) mirrors value order (descending) — they agree only on already-sorted input.