Как интерпретатор Python обрабатывает строку с логированием результата функции и почему это может быть дорого по ресурсам

Что проверяют

Знаете ли вы, что аргументы функции в Python вычисляются до её вызова, а logging откладывает только форматирование, но не вычисления. Следом обычно просят переписать строку так, чтобы при выключенном DEBUG она почти ничего не стоила.

Как отвечать

Разберите строку logger.debug(f"Result: {compute(data)}") по шагам:

• вызов compute(data): выполняется всегда, независимо от уровня логгера, потому что это аргумент;
• сборка f-строки: у результата вызывается __format__ (для большинства объектов это str()), создаётся новая строка. Для большого словаря или датафрейма это мегабайты и заметное время;
• проверка уровня: только теперь Logger.debug вызывает isEnabledFor, видит, что DEBUG выключен, и выбрасывает готовую строку. Работа сделана впустую;
• если уровень включён: создаётся LogRecord с именем потока и процесса, findCaller проходит по стеку в поисках места вызова, затем каждый хендлер берёт блокировку и синхронно пишет в файл или stdout. На горячем пути это уже I/O.

Как исправлять:

• ленивое форматирование: logger.debug("Result: %s", result). Строка соберётся, только если запись реально уйдёт в хендлер;
• охрана дорогих вычислений: if logger.isEnabledFor(logging.DEBUG): вокруг тяжёлого вызова, %s его не спасёт;
• вынос записи из потока: QueueHandler и QueueListener, чтобы медленный диск или сеть не тормозили обработку запросов;
• линтеры: pylint предупреждает о f-строках в логировании (logging-fstring-interpolation), в ruff есть такое же правило в группе G.

Где спотыкаются

Считают, что %s-стиль делает ленивым всё выражение. Нет: logger.debug("%s", compute()) по-прежнему вызывает compute(), откладывается лишь подстановка в шаблон.

Советуют f-строки как «самый быстрый способ форматирования» и для логов тоже. В обычном коде это верно, но в логировании f-строка собирается всегда, даже когда сообщение никто не увидит.

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