How Do Lambdas Work in Python?

A lambda creates a function without giving it a name. The syntax is the word lambda, then a list of parameters, then a colon, and then a single expression whose value becomes the return value.

people = [('Ada', 36), ('Grace', 45), ('Alan', 41)]

# Sort by age, and then by name.
print(sorted(people, key=lambda person: person[1]))
print(sorted(people, key=lambda person: person[0]))

# A lambda is an expression, so it can be assigned to a name.
double = lambda x: x * 2
print(double(21))                    # 42

# Default values work here too, just as they do in a def.
adder = lambda a, b=10: a + b
print(adder(5))                      # 15

The two sorted calls produce different orders. Sorting by age gives Ada, Alan, Grace, and sorting by name gives Alan, Grace, Ada. The lambda is exactly the function that the sort protocol asks for, because it takes one argument and gives back one value that can be compared.

Now the comparison with def. These two definitions do exactly the same job.

def double_def(x):
    return x * 2


double_lambda = lambda x: x * 2

print(double_def(4), double_lambda(4))    # 8 8

They differ in three ways. A def gives the function a name that shows up in tracebacks, in help(), and in the profiler, while a lambda that is assigned to a variable does not, because the function object keeps the same anonymous placeholder name. A def can contain statements and therefore several lines of logic, while a lambda is a single expression. And a def supports a docstring, type annotations, and a comment at the end that explains what it does.

The one thing that a lambda does better is being used directly as an argument, and that is why it appears in sorted(key=...), in map, in filter, and in any callback that a library expects.

The restriction is a deliberate design decision that comes from PEP 8 and from the language reference. The body of a lambda is a single expression and not a block of statements, so it cannot contain an assignment, a loop, a try block, or a return statement. That limitation exists because a lambda with a statement body would have to duplicate the whole def machinery, including local scope, argument handling, and tracebacks, and the resulting syntax would be a second and worse way of defining a function.

The cost of that decision is that a lambda cannot be given a docstring or a comment, which means that a lambda nobody can explain is undocumented by its very nature. The guidance in PEP 8 is explicit. Do not assign a lambda to a name, use def instead, and save lambdas for the cases where they are passed straight to an argument.

Concretely, a lambda makes the code worse when it does more than one simple transformation, when it needs a comment to explain itself, when it takes values from an enclosing scope and the reader has to work out when those values change, or when it is assigned to a name and then used in several places. In each of those cases a named def with a docstring is shorter to read and much easier to test.

The genuine wins are narrow but real. A short key function for sorted, a one-line condition for filter, a simple transformation for map, or a callback that is handed directly to an API. In those positions a lambda removes a name that would only be used once and it keeps the logic right next to the call that needs it.

A good summary for an interview is that lambdas are expressions, so they fit where an argument is expected, and everything else belongs in a def.