Ana wants to see the Papyrus catalog sorted by price, to know which book is the cheapest, and to filter the ones that are in stock. All those operations have something in common: a main function (sorted(), min(), a filter) needs you to tell it what criterion to work with — and that criterion is usually a tiny, single-expression function that doesn't deserve a def with a name, a docstring and its own slot in the file. For those cases Python offers lambda functions: anonymous one-line functions written right where they're used. In this lesson you'll learn their syntax, when they're a good idea and when they're not (PEP 8 has a firm opinion), and you'll put them to work with sorted(), min()/max(), map() and filter() — comparing the last two with the comprehensions from module 2, which often beat them.

1. Syntax: anatomy of a lambda
2. Lambda versus def: when to and when not to
3. The key parameter: sorting with sorted()
4. min() and max() with a criterion
5. map() and filter() versus comprehensions
6. Project: the Papyrus catalog sorted by price

A lambda is a nameless function reduced to its bare minimum:

Let's compare it with its def equivalent:

Piece-by-piece correspondence:

Key restriction: the body must be one expression — something that produces a value. Operations, function calls, f-strings and the ternary from module 2 ("out of stock" if stock == 0 else "available") all fit, but not statements: no assignments, no while, no for as a loop, no multiple lines. If you need those, you need a def.

A lambda can take several parameters (lambda title, price: f"{title}: {price} EUR") and even default values, although in practice the vast majority take one or two.

You can run a lambda directly, and even store it in a variable:

That second line works... and PEP 8 explicitly discourages it: if you're going to give it a name, use def. The reasons are practical:

• With def with_vat(base): ..., errors and debugging tools show the name with_vat; an assigned lambda shows up as the anonymous <lambda>, harder to track down.
• def allows a docstring, multiple lines, and grows without rewrites.
• You gain nothing: with_vat = lambda ... takes up as much room as the def and communicates less.

So what are they for? For passing as an argument to another function, written at the exact point where they're used. That's their home turf:

That a function can be passed as an argument shouldn't surprise you at this point: in Python functions are values, like numbers or strings. find_book (without parentheses, lesson 03-01) is a value that names a function; a lambda is the same thing, but without going through a name.

sorted(sequence) returns a new sorted list (the original doesn't change):

But Ana doesn't want to sort loose prices or bare titles: she wants to sort books by price. First we pair up title and price with zip() (previous lesson) and then the keyword argument key comes in: a function that, applied to each element, produces the value to sort by.

How it works on the inside: for each tuple book, sorted() calls the lambda, gets book[1] (the price) and sorts the tuples by comparing those values. The lambda doesn't sort anything; it only answers the question "which of your data should I compare you by?".

Useful variants:

reverse=True flips the order — another keyword argument, like the ones from lesson 03-02. And key=lambda t: t.lower() solves the classic problem of capital letters disturbing alphabetical order.

min() and max() accept the same key, and answer business questions in one line:

Important detail: they return the whole element (the title-price tuple), not the value of the criterion. That's why cheapest[0] gives the title. Without key, min(prices) would give 9.95 — the price, but with no idea which book it belongs to.

Two classic functions that take another function as an argument:

• map(function, sequence): applies the function to every element (transforms).
• filter(function, sequence): keeps the elements for which the function returns something true (sifts).

Both are lazy, like zip(): they deliver results as they're requested, and list() materializes them.

Do these operations ring a bell? They're exactly what you did in module 2 with comprehensions:

An honest comparison:

Policy for this course: use comprehensions by default; reach for map()/filter() when the function already exists and has a name (there you don't even need a lambda). Even so, you must be able to read them: you'll run into them constantly in other people's code.

Let's put it all together in price_list.py: the catalog table sorted by price, with Luis's member prices and a small report:

Review the division of labor: zip() packs the parallel lists into per-book tuples, the key lambda points to the price as the criterion, sorted() sorts without touching the original data, and final_price() — our named function, because it's reused — computes the member column. Every tool in its place.

• Assigning lambdas to names (f = lambda x: ...): it works, but PEP 8 vetoes it and error tracebacks will show <lambda> instead of a useful name. Use def.
• Trying to put statements in a lambda (lambda x: y = x + 1 or multiple lines): SyntaxError. A lambda is an expression; if it doesn't fit, it's a def.
• Passing the called lambda instead of the lambda: sorted(books, key=book[1]) fails — key expects a function, not a value. The correct form is key=lambda book: book[1].
• Forgetting list() with map()/filter(): print(map(...)) shows <map object at 0x...>, not the data. Materialize it with list() or traverse it with for.
• Mile-long lambdas: if your lambda has a ternary inside another one or runs past half a line, nobody will understand it tomorrow. Extract a def with a name and a docstring.
• Believing sorted() modifies the list: it returns a new list. (Lists also have a .sort() method that does sort in place; we'll see it in module 4.)
• Tip: write the lambda with the sentence "for each element, compare me by ___" in mind. Whatever fills the blank is the body of your lambda.

With books = list(zip(catalog, prices, stocks)) (include "Faust" at 21.00 EUR with stock 0: build it with catalog + ["Faust"], etc.), print the books sorted from least to most stock, one line per book in the format <title>: N units. Then use max() with key to print which book has the most copies in stock.

Starting from prices = [12.50, 9.95, 15.90, 21.00]: (a) use map() and a lambda to get the list of member prices (use final_price(base, member=True)); (b) use filter() and a lambda to get the base prices above 12 EUR; (c) rewrite both as comprehensions; (d) write in a single comprehension "member prices of the books whose base price is above 12 EUR" and explain why map+filter would be less readable.

Ana wants the shelf labels sorted by title length (shortest first) and, for equal lengths, alphabetically. Hint: the lambda can return a tuple (criterion1, criterion2) — Python compares tuples element by element, as you saw when comparing strings. Apply it to ["Don Quixote", "Hamlet", "Faust", "The Odyssey"].

Exercise 1:

The stock is element [2] of each tuple; changing the sort criterion is a matter of changing an index in the lambda.

Exercise 2:

With map+filter, version (d) would be list(map(lambda b: final_price(b, member=True), filter(lambda b: b > 12, prices))): two lambdas, two nested calls, and it reads from the inside out. The comprehension expresses the same thing left to right, like a sentence.

Exercise 3:

The lambda returns (length, title): Python sorts by length first and uses the title as the tiebreaker. "Faust" (5 letters) and "Hamlet" (6) need no tiebreak; "Don Quixote" and "The Odyssey" tie at 11 characters (the space counts) and alphabetical order settles it — "Don Quixote" before "The Odyssey". Without the second element of the tuple, the order between the two 11-character titles would depend on their original position.

Lambdas complete your function toolbox: the syntax lambda params: expression, a single-expression body with an implicit return, and a well-fenced territory — throwaway criteria for sorted(), min(), max(), map() and filter(), never substitutes for def when logic deserves a name (so says PEP 8). Along the way, the Papyrus catalog now sorts by price, by stock, or by whatever a one-line lambda says, and you know when a comprehension expresses the same thing more clearly. But there's a growing problem: final_price() is copied into price_list.py, and find_book() lives locked inside menu.py. We write functions to reuse them... and we keep copying them from file to file. The next lesson solves exactly that: modules and packages — we'll create papyrus_utils.py, the shop's first module of its own, and any script will be able to import its functions with a single line.