Читаемость Python: почему умный однострочник хуже пяти строк

Вложенный list comprehension с двумя условиями и walrus-оператором проходит ревью за минуту: reviewer видит, что код работает, и ставит апрув. Через полгода тот же reviewer открывает эту строку в дебаггере продакшена, ставит точку останова — и не может понять, на каком из трёх вложенных for падает KeyError. Точка останова одна на всю строку. Пошагово пройти нечего.

Это не спор о вкусах. Читаемость кода на Python — это измеримая цена: время на понимание при отладке, гранулярность стектрейса, возможность поставить брейкпоинт. Разберём, где однострочник действительно лучше, а где он платит будущим временем за сиюминутную краткость. Речь про CPython 3.11+, но принципы версии не касаются.

Задача: отфильтровать и преобразовать список словарей

Пусть есть список заказов, из которых нужно взять оплаченные, посчитать сумму со скидкой и собрать в словарь по id. Очевидное «питоничное» решение — comprehension:

# Python 3.11
orders = fetch_orders()

result = {
    o["id"]: round(o["amount"] * (1 - o.get("discount", 0)), 2)
    for o in orders
    if o["status"] == "paid" and o["amount"] > 0
}

Работает. Пока данные чистые. Теперь представьте, что в проде один заказ пришёл без ключа amount. Traceback покажет строку с dict comprehension целиком и KeyError: 'amount'. На какой из десятков итераций упало? Какой o? Comprehension не оставляет вам переменную для осмотра — временный o уже уничтожен.

Развёрнутая версия даёт другую картину:

# Python 3.11
result = {}
for order in orders:
    if order["status"] != "paid" or order["amount"] <= 0:
        continue
    discount = order.get("discount", 0)
    price = round(order["amount"] * (1 - discount), 2)
    result[order["id"]] = price

Теперь брейкпоинт можно поставить на строку с price. В момент падения в дебаггере доступен order целиком — видно, какой именно словарь сломал логику. Стектрейс укажет конкретную строку, а не блок из шести строк, склеенных в одну.

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

Где однострочник выигрывает

Отказываться от comprehension целиком — глупость. Он выигрывает там, где выражение простое и целиком помещается в голову за один взгляд.

• Простое преобразование: [x.strip() for x in lines] читается мгновенно и лучше цикла из трёх строк.
• Одно условие фильтрации: [u for u in users if u.active] — понятно без комментариев.
• Генераторное выражение в агрегате: sum(o.amount for o in paid_orders) — идиоматично и не создаёт промежуточный список.

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

Тернарный оператор: где он ломается

Вложенный тернарный — отдельная ловушка. Такое:

label = "vip" if score > 90 else "pro" if score > 50 else "basic"

читается справа налево через паузу. А теперь то же самое явно:

if score > 90:
    label = "vip"
elif score > 50:
    label = "pro"
else:
    label = "basic"

Второй вариант длиннее на четыре строки и в разы быстрее читается. С Python 3.10 сюда же просится match/case, если ветвление идёт по структуре, а не по диапазону чисел.

Сравнение по цене

Отдельно про diff в code review: если в однострочнике поменялось одно условие, git покажет изменение всей строки, и reviewer вынужден перечитывать целиком. В развёрнутом блоке diff подсветит ровно ту строку, где логика поменялась.

Инструменты, которые ловят это до ревью

Субъективный спор «читаемо / нечитаемо» частично снимается измеримой метрикой — цикломатической сложностью. Она считает число независимых путей через код.

• Ruff (замена flake8, актуален в 2024–2025): правило C901 ругается на функции выше порога сложности. Порог задаётся в pyproject.toml секцией [tool.ruff.lint.mccabe] — точное имя ключа сверьте в документации Ruff вашей версии, оно менялось при переносе настроек под lint.
• Radon считает сложность и выдаёт оценку от A до F: radon cc yourfile.py -a.

Comprehension с двумя if и тернарником внутри поднимает цифру сложности не хуже, чем развёрнутый цикл, — линтер не обманешь короткой строкой. Это хороший аргумент в споре: не «мне не нравится», а «сложность 12 при пороге 10».

Цикломатическая сложность

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

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

Не переписывайте весь проект под линейные циклы — это другая крайность. Начните с точечной дисциплины:

1. Добавьте Ruff в pre-commit с включённым правилом C901 и разумным порогом (10–12 для начала).
2. На ревью задавайте один вопрос к каждому комплексному однострочнику: «где здесь поставить брейкпоинт, если это упадёт в проде?». Если ответ «нигде» — просите развернуть.
3. Правило большого пальца: одна строка — одна мысль. Фильтр плюс преобразование плюс дефолт для отсутствующего ключа — это три мысли, им тесно в одной строке.

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