lambda: то же самое, что def, кроме двух вещей — и знаменитая ошибка с циклом не из их числа

База: обычная функция, записанная выражением

Функцию в Python можно передать аргументом — и стандартная библиотека этим пользуется постоянно. sorted, min, max, filter принимают функцию, потому что им нужен не готовый алгоритм, а правило: по какому значению сравнивать, что считать подходящим.

Обычно такую функцию сначала объявляют, а потом передают:

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

lambda — способ записать ровно ту же функцию выражением и поставить её прямо туда, где она нужна:

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

Обе записи дают функцию, обе делают одно и то же. Разница в том, что во второй у функции нет отдельного имени и отдельного места в файле.

Отсюда и ответ на вопрос «когда стоит писать так». Когда функция маленькая, нужна ровно в одном месте — в самом вызове, — и отдельное имя для неё скорее мешает: заставляет читателя отвести глаза, найти определение и вернуться обратно, чтобы узнать то, что помещалось в полстроки.

И обратное правило из того же соображения: как только имя нужно — функция вызывается из нескольких мест, ей нужна аннотация типа, её имя должно быть видно в трассировке при падении, — пишут def. Это же говорит и PEP 8, возражая против записи f = lambda ...: в ней имя вроде бы есть, а в трассировке его нет.

Этого уже достаточно, чтобы ответить на базовый вопрос собеседования: lambda — та же функция, записанная выражением, и уместна она там, где отдельное имя ухудшает читаемость. Всё дальнейшее — про то, чем именно lambda отличается от def (отличий немного, и скорости среди них нет), про знаменитую ошибку с циклом, которая к lambda не относится, и про то, что на самом деле показывают замеры.

Механизм 1: один тип, один байт-код, одно время

Начнём с того, что проверяется тремя строками.

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

type(named) is type(anon) — True, оба function. Байт-код тела совпадает инструкция в инструкцию:

RESUME  LOAD_FAST  LOAD_CONST  BINARY_OP  RETURN_VALUE

Время вызова — 22,7 нс у def против 22,7 нс у lambda на 3.13.7. Разница меньше разброса между запусками; в повторных прогонах порядок меняется местами. Утверждение здесь именно такое: измерять нечего.

Справочник описывает lambda одной строкой грамматики и говорит, что выражение lambda arguments: expression yields a function object (порождает объект-функцию) — тот же объект, что делает def.

Механизм 2: отличие первое — имя

__name__ у лямбды — <lambda>, и это видно там, где важнее всего. Две функции, которые падают одинаково:

def boom_named(x): return int(x)
boom_anon = lambda x: int(x)
 
boom_named("тест")   # ValueError — и то же самое у boom_anon

В трассировке они выглядят по-разному:

последний кадр (def):    boom_named
последний кадр (lambda): <lambda>

Отсюда рекомендация PEP 8, у которой есть причина, а не вкус: Always use a def statement instead of an assignment statement that binds a lambda expression directly to an identifier (Всегда используйте инструкцию def вместо присваивания, связывающего лямбда-выражение прямо с именем) — потому что the name of the resulting function object is specifically 'f' instead of the generic '<lambda>'. This is more useful for tracebacks (имя получившегося объекта-функции — именно 'f', а не безликое '<lambda>'. Это полезнее для трассировок).

То есть запрет касается только случая f = lambda .... Передать лямбду аргументом — sorted(data, key=lambda x: x[1]) — PEP 8 не запрещает: там имени и не предполагалось.

Механизм 3: отличие второе — тело обязано быть выражением

Справочник: lambda forms can only contain expressions, not statements (формы lambda могут содержать только выражения, но не инструкции). Проверено компиляцией, что именно не проходит:

Последняя строка — про другое: аннотацию запрещает не правило «только выражения», а грамматика самой лямбды, и PEP 3107 говорит об этом прямо. На практике она важнее остальных: лямбду нельзя аннотировать. Если у функции должен быть тип — это def, и не из вкусовых соображений.

Механизм 4: ошибка, которая не падает

А теперь код, который не падает, ничего не предупреждает — и возвращает не то.

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

Это не про lambda. FAQ заканчивает объяснение фразой, которую обычно не дочитывают: Note that this behaviour is not peculiar to lambdas, but applies to regular functions too (Заметьте, что это поведение свойственно не только лямбдам, но и обычным функциям). Проверено запуском — цикл с обычным def даёт те же [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 здесь ни при чём

Причина видна в памяти: у трёх функций одна ячейка замыкания. Ячейка (cell) — отдельный объект, который CPython заводит для переменной, если на неё смотрит не только та функция, где она создана; ссылки на такие объекты функция держит в __closure__. Проверено — множество id ячеек содержит ровно один элемент, и в ячейке лежит 2.

Так это выглядит не в учебном примере: три проверки, собранные в цикле, получают один порог — последний. [lambda v: v > t for t in (10, 100, 1000)] пропускает 3 значения вместо 6, и ни одного исключения при этом нет.

Обход — аргумент по умолчанию, потому что он вычисляется в момент создания функции:

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

У таких функций __closure__ равен None: замыкания нет вовсе, значение лежит в самой функции.

Чем включение отличается от цикла

Здесь есть деталь, которой нет в FAQ: он показывает пример на for-цикле, а у включения переменная ведёт себя иначе — ячейка одна и там и там, но живёт она по-разному.

То есть в цикле функции держат ссылку на переменную, которая живёт дальше и которую можно испортить позже. У включения своя область видимости, наружу ничего не выходит — но ячейка у трёх функций всё равно одна, и результат одинаковый.

Глубже: сколько это стоит на самом деле

Три способа достать один и тот же ключ; в таблице — время одной сортировки списка из 200 кортежей, лучшее из шестидесяти чередующихся кругов по 2 000 сортировок.

Колонки читаются по отдельности: сборки, на которых сняты эти числа, различаются не только версией языка. Смотреть надо на строки внутри одной колонки.

Первые две строки неразличимы — и это ожидаемо, объект в обоих случаях одного и того же типа. А itemgetter быстрее обоих в полтора раза, и эта разница между запусками устойчива.

Причина не в синтаксисе: itemgetter — вызываемый объект, написанный на C, и на каждый элемент не создаётся кадр интерпретатора. То же верно для attrgetter и methodcaller.

У «полутора раз» есть граница, и назвать её важнее самого числа. Замерялась одна операция — сортировка списка из 200 кортежей по одному элементу; в практике этого же урока, на других данных и другой машине, тот же переход дал больше двух раз. Переносится не множитель, а направление: выигрыш даёт исчезновение вызова кода на Python, и величина его зависит от того, какую долю времени этот вызов занимал. На сортировке из десяти элементов не изменится ничего.

Поэтому практический вывод пишется от границы: спор «lambda или def» не стоит ничего ни в ту, ни в другую сторону — измеримой разницы между ними в замере нет. Если сортировка действительно горячая, смотреть надо в сторону operator, и смотреть замером на своих данных, а не выбирать между двумя способами написать одно и то же.

Глубже: история версий

Как отвечать на собеседовании

Короткий ответ: lambda — та же функция, записанная выражением. Объект получается того же типа, что и у def, с тем же байт-кодом тела; пишут её там, где функция нужна прямо в месте вызова и отдельное имя ухудшило бы читаемость.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

Первое — назвать различия по существу. Их два, и оба в грамматике и метаданных: имя (<lambda> вместо настоящего — оно и видно в трассировке) и то, что тело обязано быть выражением. Третье, грамматическое: лямбду нельзя аннотировать, и запрещает это грамматика, а не правило «только выражения». Отсюда же рамка PEP 8: он возражает не против lambda, а против записи f = lambda ..., потому что она забирает имя из трассировки.

Второе — ловушка, которую ждут: знаменитое [lambda: i for i in range(3)], дающее [2, 2, 2], к lambda отношения не имеет — обычный def в цикле ломается так же, и FAQ говорит это прямо. Причина в том, что три функции ссылаются на одну ячейку.

Третье — если разговор ушёл в скорость, назвать настоящую развилку: lambda и def в key= неотличимы (7,97 против 7,98 мкс), а operator.itemgetter в этом замере быстрее обоих в полтора раза. Множитель — свойство этого замера, переносится направление: выигрыш даёт исчезновение вызова кода на Python.

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

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]

Проверка знаний

Чем измерено

Числа этой статьи получены этими скриптами. Каждый открывается прямо отсюда — вместе с записью прогона: на чём считали, что получилось и с каким разбросом.

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