Краткий ответ

Состояние одного экземпляра контекстного менеджера может быть перезаписано при вложенном или рекурсивном вызове. Поэтому декоратор на основе контекстного менеджера должен обеспечивать реентерабельность или создавать новый экземпляр контекста для каждого вызова.

Исторический контекст

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

Такой подход удобен, но меняет требования к жизненному циклу объекта: один экземпляр декоратора может обслуживать несколько вызовов функции, в том числе вложенных.

Постановка проблемы

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

Если для состояния используется одно поле экземпляра, внутренний вызов может затереть данные внешнего. После выхода восстановится только последнее сохранённое значение, а исходное состояние будет потеряно или восстановлено неправильно.

Подробное решение

У реентерабельного контекстного менеджера каждый вход должен иметь независимое состояние либо хранить состояния стеком. Простого требования «методы __enter__ и __exit__ существуют» недостаточно: объект обязан корректно переживать вложенные входы и выходы.

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

from contextlib import ContextDecorator

class Trace(ContextDecorator):
    def __init__(self):
        self.depth = 0

    def __enter__(self):
        self.depth += 1
        print("enter", self.depth)
        return self

    def __exit__(self, exc_type, exc, tb):
        print("exit", self.depth)
        self.depth -= 1
        return False

trace = Trace()

@trace
def visit(n):
    if n:
        visit(n - 1)

В этом примере состояние depth корректно хранится как счётчик. Но если вместо него контекстный менеджер сохранял бы единственное предыдущее значение, внутренний вход перезаписал бы его. Варианты исправления — использовать стек состояний, локальное состояние вызова или метод создания нового экземпляра контекста для каждого применения.

Создание нового экземпляра обычно безопаснее для контекстов с изменяемым состоянием, но требует явно отделить настройки контекста от его рабочего состояния. Повторное использование одного экземпляра дешевле и иногда удобно, однако оно допустимо только при доказанной реентерабельности.

Ситуация из практики

Сервисный декоратор временно устанавливает идентификатор арендатора перед выполнением функции. Декорированная функция может вызвать другую функцию с тем же декоратором, поэтому вызовы оказываются вложенными.

Вариант с одним полем previous_tenant прост, но небезопасен: внутренний вызов перезапишет значение, сохранённое внешним. Вариант с глобальным стеком технически решает вложенность, однако усложняет многопоточность и повышает риск утечки состояния между независимыми потоками.

Практичным решением будет хранить стек в контекстной переменной, например через механизм contextvars, либо создавать отдельный экземпляр контекста для каждого вызова. Для серверного кода предпочтителен первый вариант, если состояние должно корректно работать при асинхронном выполнении; он сохраняет вложенность без общей изменяемой переменной.

Что кандидаты часто упускают

Достаточно ли создавать новый экземпляр контекста для каждого последовательного вызова?

Нет. Последовательные вызовы и вложенные вызовы — разные требования. Новый экземпляр на каждый внешний вызов защищает от повторного использования между вызовами, но фабрика должна срабатывать также для каждого вложенного применения декоратора.

Можно ли считать контекстный менеджер реентерабельным, если его __exit__ всегда вызывается?

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

Почему потокобезопасность не гарантирует корректность при рекурсии?

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