Lambda functions — anonymous, used with map - filter: Visual walkthrough

Step 1 — A function is a machine with one slot

WHAT. Before we touch a lambda, picture what any function is: a box with an input slot on the left and an output chute on the right. You drop something in, a rule runs, one thing comes out.

WHY. Everything on this page — map, filter, sorted's key — is just "hand a machine to another machine". So we must first agree, visually, on what a single machine looks like. If a machine is fuzzy, a machine-that-uses-machines is hopeless.

PICTURE. Below, the same rule "multiply by 2" is drawn twice: once as a named machine built with def, once as an anonymous sticky-note machine written with lambda. Same insides, same behaviour — only the label differs.

Figure — Lambda functions — anonymous, used with map - filter

This is why a lambda is called first-class: the whole sticky note is itself a value you can hand to someone else — exactly what we do next.

Step 2 — `map`: run the machine on every item

WHAT. map takes two things: a machine f and a basket of items it. It walks the basket, drops each item into f, and lines up the outputs in the same order.

WHY. We reach for map (not a hand-written loop) when the job is "transform every element the same way". It answers the question "what does my whole list look like after applying this one rule to each piece?" — nothing is added or removed, only changed.

PICTURE. The basket [1, 2, 3, 4] flows left-to-right through the machine lambda x: x * 2. Watch each item enter the box and leave doubled. The output basket has the same length — one out for every one in.

nums = [1, 2, 3, 4]
list(map(lambda x: x * 2, nums))   # [2, 4, 6, 8]

We say list(...) because map hands back a lazy conveyor belt, not a finished basket — Step 5 makes this visible.

Step 3 — `filter`: a bouncer, not a transformer

WHAT. filter also takes a machine f and a basket. But now f is a predicate — a machine whose output is only yes or no (True/False). filter keeps each item unchanged if the answer is yes, and drops it if no.

WHY. We reach for filter when the job is "select some elements, change none". It answers "which items pass my test?" Contrast with Step 2: map never removes anything; filter never alters anything. Two opposite jobs, same shape of call.

PICTURE. Same basket [1, 2, 3, 4, 5, 6] meets the test lambda x: x % 2 == 0 ("is x even?"). The green door opens for evens; odds bounce off. The output basket is shorter or equal — never longer.

nums = [1, 2, 3, 4, 5, 6]
list(filter(lambda x: x % 2 == 0, nums))   # [2, 4, 6]

Step 4 — Nesting them: thin first, then transform

WHAT. Because both machines take-a-basket-and-return-a-basket, you can feed one's output into the other. Here: filter keeps the odds, then map squares whatever survives.

WHY. We nest to compose two simple jobs into one pipeline instead of writing a bespoke loop. The ordering matters: reading Python inside-out, the innermost call runs first.

PICTURE. The basket splits into two stages. Stage 1 (green, filter) drops the evens, leaving [1, 3, 5]. Stage 2 (blue, map) squares each survivor into [1, 9, 25]. Follow the single item 3: it passes the bouncer, then gets squared to 9.

$map (stage 2: transform lambda x: x*x, stage 1: select — runs first filter(lambda x: x%2==1, nums))$

nums = [1, 2, 3, 4, 5]
list(map(lambda x: x*x, filter(lambda x: x % 2 == 1, nums)))   # [1, 9, 25]

Often a list comprehension reads even clearer: [x*x for x in nums if x % 2 == 1].

Step 5 — The degenerate case: the belt runs out (laziness)

WHAT. map and filter do not hand you a finished basket. They hand you a conveyor belt (lazy iterator) that produces items only when asked, and runs out after one pass.

WHY. This is the #1 surprise, so it gets its own step. Laziness saves memory (nothing is computed until pulled), but it means a second attempt to read the same belt finds it empty — every item already fell off the end.

PICTURE. Left panel: printing the belt directly shows the cryptic <map object ...> — you're looking at the machine, not its output. Right panel: the first list(belt) drains it fully; a second list(belt) scoops up nothing → [].

belt = map(lambda x: x * 2, [1, 2, 3])
print(belt)          # <map object at 0x...>  ← the machine, not the answer
list(belt)           # [2, 4, 6]  ← belt now drained
list(belt)           # []         ← nothing left to scoop

Step 6 — Another degenerate case: `filter(lambda x: x, items)`

WHAT. If the predicate is just the item itself — lambda x: x — then filter keeps every item whose own value counts as truthy, and drops the falsy ones.

WHY. This is a boundary of Step 3: what if the "test" isn't a comparison but the raw item? Python decides yes/no by asking whether the value is truthy. So this one-liner strips out 0, '', None, [], False — a genuinely useful idiom, not a bug.

PICTURE. The mixed basket [0, 1, '', 'hi', None, 5] meets the identity door. Falsy items (0, '', None, shown in red) bounce; truthy items (1, 'hi', 5, shown in green) pass.

items = [0, 1, '', 'hi', None, 5]
list(filter(lambda x: x, items))   # [1, 'hi', 5]

Step 7 — A machine that compares: `sorted`'s `key`

WHAT. `sorted` can take key=<a machine>. For each item it asks the machine "what single value should I compare you by?", then orders items by those values — leaving the items themselves whole.

WHY. By default sorted compares whole items (tuples compare by first element). When we want to sort by a different field, we hand it a lambda that extracts that field. This is the same "hand over a machine" idea, now used to produce comparison keys instead of transformed items.

PICTURE. The list [(1,'b'), (3,'a'), (2,'c')] with key=lambda p: p[1] (grab the letter). Each pair projects down to its letter 'b','a','c'; sorting those alphabetically reorders the pairs to [(3,'a'),(1,'b'),(2,'c')].

$sorted (pairs, key = one pair in lambda p : its 2nd element out p[1])$

pairs = [(1, 'b'), (3, 'a'), (2, 'c')]
sorted(pairs, key=lambda p: p[1])   # [(3, 'a'), (1, 'b'), (2, 'c')]

The one-picture summary

Everything compresses to one image: a lambda is a tiny machine, and map / filter / sorted-key are bigger machines that borrow it and apply it across a whole basket — transforming, selecting, or comparing.

Recall Feynman retelling — say it to a 12-year-old

Imagine a factory line. A lambda is a sticky-note rule you scribble — "double it", "is it even?", "grab the letter". You don't bother naming it because you'll use it once. map is a worker who takes your sticky note and does it to every item on the belt: four items in, four items out, each changed. filter is a bouncer who reads your sticky note as a yes/no test and only lets the "yes" items through: the belt comes out shorter, but each item is untouched. You can chain them — bouncer first to thin the crowd, then the worker to transform who's left. Two catches worth remembering. First, map and filter don't hand you a finished box — they hand you the belt itself, and it only runs once; you must list() it to catch the items, and a second scoop finds an empty belt. Second, when the sticky note is just "keep the item if it's real" (lambda x: x), the bouncer throws out all the empties — the 0s, blanks, and Nones. Same tiny rule, four different big jobs.

Connections

Functions and def — the named twin of the anonymous machine in Step 1.
First-class functions — why a lambda can be handed over to map/filter.
Higher-order functions — map, filter, sorted are exactly these: they take a machine.
Iterators and lazy evaluation — the one-pass belt of Step 5.
List comprehensions — a readable rewrite of the Step 4 pipeline.
sorted and key functions — the Step 7 comparison-key idea in full.