Функциональный стиль в Python: где он уместен, а где вредит

В код-ревью Python-проектов регулярно всплывает одна и та же сцена: разработчик заменяет пятистрочный цикл на однострочник с reduce и вложенным lambda, гордится компактностью, а ревьюер тратит десять минут, чтобы понять, что там происходит. Функциональный стиль в Python — не про то, чтобы всё уместить в одну строку. Это про предсказуемость: функции без побочных эффектов, неизменяемые данные, композиция вместо накопления состояния. Проблема в том, что Python — не функциональный язык, и в некоторых местах этот стиль работает против вас.

Разберём на конкретных приёмах CPython 3.11+, где функциональный подход даёт читаемый и быстрый код, а где ломает и производительность, и понятность. Кода приводить будем немного — статья про выбор подхода, а не про синтаксис отдельной функции.

Что вообще считается функциональным стилем в Python

Речь не о том, чтобы писать на Python как на Haskell. В Python функциональный стиль — это набор практик:

• функции без побочных эффектов: результат зависит только от аргументов, ничего снаружи не меняется;
• работа с неизменяемыми структурами — tuple, frozenset, замороженные dataclass;
• map, filter, comprehension вместо ручного накопления в цикле;
• функции высшего порядка: передача функций в аргументах, functools.partial, декораторы;
• композиция мелких функций вместо одной большой процедуры.

Ключевое отличие от «настоящих» функциональных языков: у Python нет оптимизации хвостовой рекурсии, ленивые вычисления есть только у генераторов, а lambda ограничена одним выражением. Всё это задаёт границы применимости.

Где функциональный стиль выигрывает

Comprehension вместо цикла с накоплением

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

# Императивно
result = []
for user in users:
    if user.is_active:
        result.append(user.email)

# Функционально
result = [user.email for user in users if user.is_active]

Второй вариант не только короче. Он сразу говорит читателю: «здесь строится новый список, исходные данные не меняются, побочных эффектов нет». Императивный вариант приходится читать построчно, проверяя, не делает ли тело цикла ещё чего-нибудь. В CPython comprehension ещё и заметно быстрее ручного append в цикле — байткод не вызывает метод списка на каждой итерации.

Генераторы для конвейеров и больших данных

Когда данных много и не нужно держать их в памяти целиком, генераторные выражения и itertools — прямое попадание. Ленивое вычисление здесь не украшение, а способ обработать файл на гигабайты, не загружая его в память:

import itertools

# Читаем большой лог построчно, фильтруем, берём первые 100 ошибок
def error_lines(path):
    with open(path, encoding="utf-8") as f:
        errors = (line for line in f if "ERROR" in line)
        yield from itertools.islice(errors, 100)

Здесь весь конвейер ленивый: строки читаются по одной, islice останавливает чтение после сотой ошибки. Императивный аналог с ручным счётчиком и break длиннее и легче ломается при доработке.

Чистые функции проще тестировать

Функция, которая принимает данные и возвращает данные, не трогая базу, файлы и глобальные переменные, тестируется без моков. Это не про синтаксис, а про архитектуру, и здесь функциональный стиль почти всегда прав. Отделяйте вычисление от ввода-вывода: пусть чистая функция считает, а тонкий императивный слой сверху читает и пишет.

Хорошее правило: побочные эффекты выталкивайте к краям программы. Ядро — чистые функции, которые легко проверить; грязь с базой и сетью держите в тонком внешнем слое.

Где функциональный стиль вредит

reduce вместо явного цикла

functools.reduce — самый частый источник нечитаемого кода. Гвидо ван Россум неслучайно вынес его из встроенных функций в модуль functools при переходе к Python 3. Сравните:

from functools import reduce

# reduce — приходится держать в голове аккумулятор и порядок
total = reduce(lambda acc, order: acc + order.amount, orders, 0)

# Обычный sum с генератором — читается сразу
total = sum(order.amount for order in orders)

Почти любой осмысленный reduce для суммирования, поиска максимума или конкатенации заменяется встроенной функцией (sum, max, min, "".join) и читается лучше. reduce оправдан редко — например, при последовательной композиции функций, — и даже там стоит подумать про явный цикл.

Вложенные map и filter с lambda

Цепочка вроде list(map(lambda x: x * 2, filter(lambda x: x > 0, data))) в Python читается хуже эквивалентного comprehension: [x * 2 for x in data if x > 0]. Причина в порядке чтения: в map/filter глаз прыгает справа налево и наружу внутрь, а comprehension читается линейно. map и filter уместны, когда функция уже есть и не нужна lambda: map(str.upper, names) нормально, map(lambda n: n.upper(), names) — уже хуже, чем comprehension.

Рекурсия вместо цикла

В Python нет оптимизации хвостовой рекурсии, а лимит глубины по умолчанию — 1000 вызовов (sys.getrecursionlimit()). Рекурсивный обход большого списка упрётся в RecursionError там, где цикл спокойно отработает. Рекурсия в Python уместна для естественно древовидных структур (обход дерева, парсинг), но не как замена итерации по плоской коллекции.

Погоня за иммутабельностью там, где она дорога

Каждое «неизменяемое обновление» создаёт новый объект. Если в горячем цикле на каждой итерации собирать новый tuple или пересобирать frozenset, вы платите аллокациями. Там, где локальная мутация не выходит за пределы функции и невидима снаружи, изменяемый список внутри чистой функции — нормально. Функция остаётся чистой, даже если внутри мутирует свой локальный аккумулятор.

Таблица: выбирайте по ситуации

Когда что выбирать: практический критерий

Не про «функциональный лучше императивного», а про то, что читается за один проход глазами и предсказуемо себя ведёт:

• Одно преобразование или фильтр — comprehension. Читается линейно, работает быстро.
• Больше двух вложенных условий или преобразований в одном comprehension — разбейте на цикл или несколько шагов. Трёхэтажный comprehension нечитаем.
• Нужно тело в две-три строки на элемент — обычный цикл или именованная функция, не lambda.
• Данные не помещаются в память или нужна ленивость — генераторы и itertools.
• Есть побочные эффекты (запись в базу, логи, сеть) — императивный цикл честнее: он не притворяется чистым.

Что ломается на практике

Три ошибки, которые встречаются в ревью чаще всего:

1. lambda в цикле с замыканием на переменную цикла. [lambda: i for i in range(3)] вернёт три функции, каждая из которых выдаст 2 — замыкание держит ссылку на i, а не её значение. Фиксируйте значение через аргумент по умолчанию: lambda i=i: i.
2. Генератор, прочитанный дважды. Генератор одноразовый. Если пройтись по нему второй раз, получите пустоту без ошибки. Для повторного прохода нужен список или itertools.tee.
3. Иллюзия чистоты. Функция выглядит функциональной, но внутри дёргает глобальный кеш или мутирует переданный список. Такой код труднее отлаживать, чем честный императивный: ожидания от «чистой» функции не совпадают с поведением.

Что делать дальше

Начните с одного правила: выталкивайте побочные эффекты к краям. Разделите код на чистое ядро (вычисления) и тонкий грязный слой (ввод-вывод) — это даст больше, чем любой отдельный map или reduce. Дальше замените ручные циклы с накоплением на comprehension там, где нет побочных эффектов, и оставьте reduce только для случаев, где встроенной функции нет. Посмотрите модуль itertools в стандартной документации — там готовые ленивые кирпичи для конвейеров, и functools с partial и lru_cache. На ревью меряйте один показатель: читается ли выражение за один проход глазами. Если нет — стиль не в тему, каким бы элегантным он ни казался автору.