lambda: the same thing as def except for two — and the famous loop bug is neither of them

Base: an ordinary function written as an expression

A function in Python can be passed as an argument, and the standard library relies on that constantly. sorted, min, max and filter take a function because what they need is not a finished algorithm but a rule: which value to compare by, what counts as a match.

Usually such a function is declared first and passed afterwards:

def second(pair):
    return pair[1]
 
rows.sort(key=second)

A lambda is a way to write exactly the same function as an expression and put it where it is needed:

rows.sort(key=lambda pair: pair[1])

Both forms produce a function and both do the same thing. The difference is that in the second one the function has no separate name and no separate place in the file.

Which answers the question of when to write it that way. When the function is small, needed in exactly one place — the call itself — and a separate name would get in the way: it makes the reader look away, find the definition and come back, all for something that fitted on half a line.

And the converse rule, from the same reasoning: as soon as a name is needed — the function is called from several places, it needs a type annotation, its name should show up in a traceback when it fails — write a def. PEP 8 says the same thing when it objects to f = lambda ...: there the name appears to exist, yet the traceback does not have it.

That is already enough to answer the basic interview question: a lambda is the same function written as an expression, and it belongs where a separate name would hurt readability. Everything below is about how exactly lambda differs from def (there are few differences, and speed is not among them), about the famous loop bug that is not about lambda, and about what the measurements actually show.

Mechanism 1: one type, one bytecode, one timing

Start with what three lines settle.

def named(x):
    return x + 1
 
anon = lambda x: x + 1

type(named) is type(anon) is True; both are function. The bytecode of the body matches instruction for instruction:

RESUME  LOAD_FAST  LOAD_CONST  BINARY_OP  RETURN_VALUE

Call time is 22.7 ns for def against 22.7 ns for lambda on 3.13.7. The gap is smaller than the run-to-run spread; in repeated runs the order swaps. The claim is exactly that: there is nothing to measure.

The reference describes lambda in a single line of grammar and says the expression lambda arguments: expression “yields a function object” — the same object def makes.

Mechanism 2: difference one — the name

A lambda's __name__ is <lambda>, and that shows up where it matters most. Two functions that fail identically:

def boom_named(x): return int(x)
boom_anon = lambda x: int(x)
 
boom_named("test")   # ValueError — and the same for boom_anon

In a traceback they look different:

last frame (def):    boom_named
last frame (lambda): <lambda>

Hence PEP 8's recommendation, which rests on a reason rather than on taste: “Always use a def statement instead of an assignment statement that binds a lambda expression directly to an identifier” — because “the name of the resulting function object is specifically 'f' instead of the generic '<lambda>'. This is more useful for tracebacks”.

Note that the rule covers only the f = lambda ... case. Passing a lambda as an argument — sorted(data, key=lambda x: x[1]) — is not what PEP 8 objects to: there was never a name to lose.

Mechanism 3: difference two — the body must be an expression

The reference: “lambda forms can only contain expressions, not statements”. Compiling each form shows exactly what does not get through:

The last row is about something else: what forbids the annotation is not the “expressions only” rule but the grammar of lambda itself, and PEP 3107 says so outright. In practice it matters most: a lambda cannot be annotated. If a function needs a type, it is a def, and not for reasons of taste.

Mechanism 4: the error that does not crash

And now code that does not crash, does not warn — and returns the wrong thing.

fns = [lambda: i for i in range(3)]
[f() for f in fns]        # [2, 2, 2], not [0, 1, 2]

This is not about lambda. The FAQ closes its explanation with a sentence people tend not to reach: “Note that this behaviour is not peculiar to lambdas, but applies to regular functions too”. Running it confirms — a loop with a plain def gives the same [2, 2, 2]:

defs = []
for i in range(3):
    def make():
        return i
    defs.append(make)
[f() for f in defs]       # [2, 2, 2] — lambda has nothing to do with it

The reason is visible in memory: the three functions share one closure cell. A cell is a separate object CPython creates for a variable more than one scope looks at; a function keeps its references to them in __closure__. Verified — the set of cell ids has exactly one element, and the cell holds 2.

Outside a teaching example it looks like this: three checks built in a loop all get one threshold — the last one. [lambda v: v > t for t in (10, 100, 1000)] passes 3 values instead of 6, with no exception anywhere.

The workaround is a default argument, because it is evaluated when the function is created:

fixed = [lambda i=i: i for i in range(3)]   # [0, 1, 2]

Such functions have __closure__ of None: there is no closure at all, the value lives in the function itself.

How a comprehension differs from a loop

There is a detail here the FAQ does not cover: its example uses a for loop, and the variable behaves differently in a comprehension — one cell either way, but a different lifetime.

In a loop the functions hold a reference to a variable that outlives the loop and can be reassigned later. A comprehension has its own scope and leaks nothing — but the three functions still share one cell, and the result is the same.

Deeper: what it actually costs

Three ways to fetch the same key; the table gives the time of one sort of a 200-element list of tuples, best of seven runs of 20,000 sorts each.

Read the columns separately: the builds these numbers come from differ by more than the language version. What to compare is rows within one column.

The first two rows are indistinguishable — as expected: it is the same kind of object either way. itemgetter is roughly 1.5× faster than either, and that gap is stable between runs.

The reason is not syntax: itemgetter is a callable written in C, and no interpreter frame is created per element. The same holds for attrgetter and methodcaller.

The “one and a half times” has a boundary, and naming it matters more than the number. What was measured is one operation — sorting a 200-element list of tuples by one item; in this lesson's own practice run, on different data and a different machine, the same move gave more than two times. What carries over is not the multiple but the direction: the win comes from a Python-level call disappearing, and its size depends on how much of the time that call took. On a ten-element sort nothing changes at all.

So the practical conclusion is written from the boundary: the "lambda or def" argument costs nothing either way — the measurement shows no difference between them. If a sort is genuinely hot, look towards operator, and look with a measurement on your own data rather than by choosing between two ways of writing the same thing.

Deeper: version history

How to answer in an interview

The short answer: a lambda is the same function written as an expression. The object it builds is of the same type as a def's, with the same bytecode for the body; you write one where the function is needed right at the call site and a separate name would hurt readability.

That is enough to answer correctly. Beyond it is what you add if the interviewer digs.

If the interviewer digs deeper

First, name the actual differences. There are two, both in grammar and metadata: the name (<lambda> instead of a real one — which is what shows up in a traceback) and the requirement that the body be an expression. A third is grammatical: a lambda cannot be annotated, and it is the grammar that forbids it, not the "expressions only" rule. Which also frames PEP 8: it objects not to lambda but to f = lambda ..., because that form takes the name out of the traceback.

Second, the trap they are waiting for: the famous [lambda: i for i in range(3)] yielding [2, 2, 2] has nothing to do with lambda — a plain def in a loop breaks the same way, and the FAQ says so outright. The reason is that the three functions point at one cell.

Third, if the conversation turns to speed, name the real choice: lambda and def in key= are indistinguishable (7.97 against 7.98 µs), while operator.itemgetter is one and a half times faster than either in that measurement. The multiple belongs to the measurement; the direction is what carries over — the win comes from a Python-level call disappearing.

Next they ask

Common misconceptions

Practice

Two exercises. Answer first, then check against the real output: in both, the right answer comes from a recorded run rather than from an editor.

lambdas = [lambda: i for i in range(3)]

defs = []
for i in range(3):
  def made():
      return i
  defs.append(made)

print([f() for f in lambdas])
print([f() for f in defs])

[2, 2, 2]
[2, 2, 2]

[2, 2, 2]
[0, 1, 2]

[0, 1, 2]
[0, 1, 2]

[0, 1, 2]
[2, 2, 2]

Knowledge check

What measured this

The numbers in this article come from these scripts. Each one opens from here, together with the record of the run: what it was measured on, what came out, and with what spread.

• bench/lambda/cost.py
• bench/lambda/identity.py
• bench/lambda/late_binding.py
• bench/lambda/silent.py