Контекстные менеджеры: два метода, одна возвращаемая истина и одна тихая потеря данных

База: зачем понадобился with

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

Поэтому освобождение пишут не «после работы», а в блоке, который выполняется в любом случае:

handle = open("data.txt")
try:
    process(handle)
finally:
    handle.close()      # выполнится и при удаче, и при ошибке

Это верно, но многословно, и повторять это приходится в каждом месте, где ресурс берут. with — та же конструкция, свёрнутая в одну строку:

with open("data.txt") as handle:
    process(handle)

Здесь open сам знает, что нужно сделать на выходе, и делает это — при обычном завершении блока, при return из середины, при исключении. Для читателя with означает ровно одно: выход из этого блока будет обработан, чем бы блок ни кончился.

Отсюда и протокол. Чтобы объект годился для with, он должен уметь две вещи: что-то сделать на входе в блок и что-то сделать на выходе из него. В Python эти две вещи называются __enter__ и __exit__; as получает то, что вернул первый, а второй вызывается на выходе.

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

Механизм 1: два метода, и оба — на типе

Справочник описывает исполнение with семью шагами. Первые пять — про вход: вычислить выражение, загрузить __enter__, загрузить __exit__, вызвать __enter__, присвоить результат цели после as.

Слово «загрузить» здесь не украшение. Оба метода ищутся неявным поиском специального метода — то есть на типе, а не на экземпляре. Присвоить их объекту нельзя:

class Plain:
    pass
 
p = Plain()
p.__enter__ = lambda: None
p.__exit__ = lambda *a: None
 
with p:          # TypeError: 'Plain' object does not
    pass         # support the context manager protocol

На 3.14 к этому сообщению добавится (missed __exit__ method): там __exit__ загружается первым, поэтому именно его имя и попадает в текст ошибки.

Второе, что видно из шага 5: as получает возвращаемое значение __enter__, а не сам менеджер. Метод, забывший return, отдаёт None:

class ReturnsNothing:
    def __enter__(self): pass
    def __exit__(self, *a): pass
 
with ReturnsNothing() as v:
    print(v)     # None

Совпадение объекта и as-переменной — не правило языка, а решение автора менеджера. open() возвращает из __enter__ сам файл, поэтому там они совпадают; contextlib.suppress возвращает себя; @contextmanager возвращает то, что стоит после yield.

Механизм 2: судьбу исключения решает истинность одного значения

PEP 343 записывает перевод with в явный try. Стоит прочитать его целиком — дальше в уроке нет ни одного утверждения, которого не было бы видно прямо здесь:

mgr = (EXPR)
exit = type(mgr).__exit__
value = type(mgr).__enter__(mgr)
exc = True
try:
    try:
        VAR = value
        BLOCK
    except:
        exc = False
        if not exit(mgr, *sys.exc_info()):
            raise
finally:
    if exc:
        exit(mgr, None, None, None)

Строка if not exit(...): raise — это и есть весь механизм подавления. Справочник формулирует то же нормативно: If the return value was true, the exception is suppressed, and execution continues with the statement following the with statement (Если возвращённое значение истинно, исключение подавляется, и выполнение продолжается с инструкции, следующей за with).

Значит, __exit__ может закончиться тремя разными способами. Первые два различает истинность возвращённого значения — именно она, а не конкретный объект: годится любая истина, будь то True, единица или непустая строка. Третий способ — метод сам бросил исключение.

У этого правила есть граница, и она названа в самой записи PEP: exit вызывается после того, как __enter__ вернул управление. До успешного входа решать нечего — __exit__ не позовут вовсе (об этом ниже отдельный раздел).

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

Как и с генераторами, интересна не та ошибка, что роняет программу. Вот разбор строк с одной битой записью:

ROWS = [
    {"id": 1, "amount": "100"},
    {"id": 2, "amount": "no data"},   # битая
    {"id": 3, "amount": "50"},
    {"id": 4, "amount": "25"},
]

Правильный вариант — suppress вокруг одной строки:

total = 0
for row in ROWS:
    with suppress(ValueError):
        total += int(row["amount"])

Неправильный отличается положением двух строк — suppress оказывается вокруг цикла:

total = 0
with suppress(ValueError):
    for row in ROWS:
        total += int(row["amount"])

Замер (одинаково на 3.13.7 и 3.14.7):

Битая запись при этом действительно пропущена — отдельный счётчик в замере получает ровно одну. Потеряно 75 из 175. Ни одного исключения, ни одной строки в логе: suppress не «пропускает ошибку», он выходит из блока целиком — ровно как записано в PEP 343, где подавление означает переход к строке после with.

Та же ошибка в виде собственного менеджера страшнее, потому что в месте вызова нет слова suppress:

class Quiet:
    def __enter__(self): return self
    def __exit__(self, *a): return True     # «чтобы не падало»

С ним та же сумма — 100.

Механизм 4: подавить группу и вырезать ветку — разные операции

Слово «подавить» в предыдущем разделе означало одно: __exit__ вернул истину, и блок кончился. С группой исключений операций становится две, и они дают разные результаты (bench/ctxmgr-async/exceptiongroup_suppress.py).

Первая — старая. __exit__ -> True над ExceptionGroup глотает группу целиком, со всеми ветками (здесь и ниже вывод скрипта приведён сокращённо — только относящиеся к делу строки):

1) __exit__ -> True над ExceptionGroup
   __exit__ увидел вложенные: ['ValueError', 'TypeError']
   выполнение продолжилось: группа проглочена целиком, обе ветки

Вторая появилась в 3.12 и работает тоньше: suppress вырезает свою ветку и пересобирает остаток. На 3.11 то же самое не подавляло вообще ничего:

3.11.15
2) with suppress(ValueError): raise ExceptionGroup('eg', [ValueError])
   наружу вышло ExceptionGroup 'eg (1 sub-exception)' вложенные: ['ValueError']
3) ... ExceptionGroup('mix', [ValueError, TypeError])
   наружу вышло 'mix (2 sub-exceptions)' вложенные: ['ValueError', 'TypeError']
   это тот же объект, что бросали: True

3.12.3 и новее
2) РЕЗУЛЬТАТ: подавлено, выполнение продолжилось
3) наружу вышло 'mix (1 sub-exception)' вложенные: ['TypeError']
   это тот же объект, что бросали: False

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

Работает это и вглубь: ValueError, лежавший во вложенной группе, на 3.12 из неё вырезан, а на 3.11 остался на месте.

Тут стоит снять частое заблуждение о причине. BaseExceptionGroup.split, которым это сделано, существует с 3.11 — замер вызывает его напрямую и на 3.11, и результат тот же. Изменился не split, а suppress, который начал его звать: до 3.12 его __exit__ умещался в одну строку — return exctype is not None and issubclass(exctype, self._exceptions), — и группа под это условие просто не подходила.

Рядом с suppress полезно помнить except*. Он делит группу тем же способом — split возвращает the pair (match, rest) where match is subgroup(condition) and rest is the remaining non-matching part (пару (match, rest), где match — это subgroup(condition), а rest — оставшаяся несовпавшая часть), — и справочник описывает его так:

Практический вывод для кода, который пользуется TaskGroup или любой другой структурной конкурентностью: suppress(ValueError) там означает не «глушить всё», а «вынуть из группы ValueError и отдать наружу остальное». Начиная с 3.12.

Механизм 5: если __enter__ бросил исключение, уборки не будет

Гарантия справочника сформулирована с условием, и условие легко потерять при чтении: if the __enter__() method returns without an error, then __exit__() will always be called (если метод __enter__() вернул управление без ошибки, то __exit__() будет вызван обязательно).

То есть до успешного входа гарантии нет никакой:

class FailsOnEnter:
    def __enter__(self):
        self.acquire()          # первая половина удалась
        raise RuntimeError      # вторая — нет
    def __exit__(self, *a):
        self.release()          # НЕ БУДЕТ ВЫЗВАН

Проверено запуском: __enter__ пишет в журнал до raise, и после падения там остаётся только эта запись — __exit__ не добавил ничего. Практический вывод — __enter__ должен либо захватить всё, либо не захватить ничего: собственный try/except внутри него, а не надежда на __exit__.

Справочник отдельно говорит, что with A(), B(): равносильно вложенным with. Сложив это с правилом выше, получаем: если B.__enter__ упал, A.__exit__ отработает, а B.__exit__ — нет. Проверено запуском, на классах:

вход A | вход B | выход A

У @contextmanager с try/finally та же строка выглядит иначе — там уборка для B всё-таки выполнится. Почему — в следующем разделе.

Механизм 6: @contextmanager — где живёт исключение

Генераторная форма короче, и в ней не видно ни __exit__, ни трёх его аргументов. Строка после yield читается как обычная уборка — а её пропустит любое исключение:

@contextmanager
def naive():
    resource = acquire()
    yield resource
    release(resource)        # при исключении сюда не придут

Документация contextlib объясняет, почему: If an unhandled exception occurs in the block, it is reraised inside the generator at the point where the yield occurred (Если в блоке возникает необработанное исключение, оно возбуждается заново внутри генератора в той точке, где произошёл yield). Исключение не «происходит снаружи» — оно бросается в точку yield, и дальше ведёт себя как обычное исключение внутри функции: разматывает кадр, минуя строки после yield.

Проверено запуском:

Из того же свойства следует и способ подавить исключение в генераторной форме: не return True, а обычный except, из которого не перебрасывают:

@contextmanager
def catches():
    try:
        yield
    except ValueError:
        pass            # исключение подавлено

Документация предупреждает об этом прямо: If an exception is trapped merely in order to log it… the generator must reraise that exception (Если исключение перехвачено лишь ради того, чтобы его записать в журнал… генератор обязан возбудить это исключение заново).

Есть и место, где генераторная форма ведёт себя лучше класса. Если код до yield обёрнут в try/finally, а генератор упал ещё до yield, finally всё равно отработает: исключение разматывает кадр генератора и проходит через него. У класса в той же ситуации не вызывается ничего — это и есть та разница, из-за которой строка вход A | вход B | выход A выше помечена «на классах».

Механизм 7: ExitStack — вложенность, которой нет в коде

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

Второе предложение — это не оговорка, а то, ради чего абзац стоит читать. Оно проверяется прямо (bench/ctxmgr-async/exitstack.py, вывод одинаков на 3.11–3.14):

4) inner вернул True — блок завершился без исключения:
   exit  inner (видит ValueError)
   exit  outer (видит None)
   outer увидел None, потому что inner уже подавил

5) наружу вышло: KeyError 'подмена'
   exit  inner (видит ValueError)
   exit  outer (видит KeyError)
   outer увидел уже KeyError, а не исходный ValueError

То есть внешний __exit__ видит не то исключение, которое случилось, а то, которое осталось после внутреннего. Логирование «что упало» на внешнем уровне поэтому врёт, если внутри кто-то подменяет.

Остальное поведение — то же, что у вложенных with, и потому предсказуемо: падение третьего __enter__ закрывает первые два в обратном порядке и не открывает четвёртый; enter_context(object()) даёт TypeError сразу, а не позже. Отдельно стоит pop_all: он переносит зарегистрированную уборку в другой объект, и тогда выход из with ничего не закрывает — закрывает тот, кому уборку передали. Это штатный способ вернуть наружу уже открытый ресурс, не закрыв его на выходе из функции, которая его открыла.

Механизм 8: async with — тот же протокол, другие имена

Асинхронный вариант не добавляет ни одного нового правила. Модель данных описывает оба метода одной формулировкой:

Отсюда всё остальное: as получает возвращённое значение, истина из __aexit__ подавляет исключение, порядок тот же. Проверено запуском (bench/ctxmgr-async/async_protocol.py), и вывод одинаков на 3.11–3.13.

Практически важны две вещи, которых у синхронного with быть не может.

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

4) чередование с фоновой задачей: ['фон-0', 'тело начало', 'фон-1', 'тело кончило', 'фон-2']

Блокировка, взятая на входе в такой менеджер, держится через await — и всё, что о блокировках сказано в уроке про async, начинается здесь.

Вторая: протоколы не взаимозаменяемы. Синхронный менеджер под async with не работает и наоборот:

3a) async with над синхронным менеджером -> TypeError: 'SyncOnly' object does not support the asynchronous context manager protocol
3b) with над асинхронным менеджером     -> TypeError: 'AsyncOnly' object does not support the context manager protocol

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

3a) ... (missed __aexit__ method) but it supports the context manager protocol. Did you mean to use 'with'?
3b) ... (missed __exit__ method) but it supports the asynchronous context manager protocol. Did you mean to use 'async with'?

Для смешанного случая есть AsyncExitStack: он держит и синхронные, и асинхронные менеджеры в одном стеке и закрывает их в обратном порядке регистрации, не разделяя по виду. У него нет close — только aclose, и это записано в документации, а не выведено из поведения.

Глубже: один объект — один вход

Документация называет результат @contextmanager однократным и приводит пример, который заканчивается так:

RuntimeError: generator didn't yield

На всех четырёх версиях получается другое. Пример из документации, запущенный дословно на 3.11.15, 3.12.3, 3.13.7 и 3.14.7, даёт:

AttributeError: '_GeneratorContextManager' object has no attribute 'args'

Причина видна в исходниках. Lib/contextlib.py на теге v3.13.7, строки 118–125:

def __enter__(self):
    # do not keep args and kwds alive unnecessarily
    # they are only needed for recreation, which is not possible anymore
    del self.args, self.kwds, self.func
    try:
        return next(self.gen)
    except StopIteration:
        raise RuntimeError("generator didn't yield") from None

Удаление атрибутов стоит до next(self.gen), поэтому второй вход падает раньше, чем дело доходит до генератора. Задокументированный RuntimeError живёт в ветке except StopIteration — до неё второй вход просто не доходит.

Практического вывода это не меняет: повторно входить надо не в объект, а вызывать функцию заново — with careful(): каждый раз. Но знать стоит: если в чужом коде встретился AttributeError: ... has no attribute 'args', это не загадка, а повторный вход в уже использованный менеджер.

Глубже: что изменилось в 3.14

Время двух версий нельзя ставить рядом: сборки 3.13.7 и 3.14.7 различаются не только версией языка — у 3.14 включён --with-tail-call-interp — тот самый флаг, которому «Что нового в 3.14» приписывает a geometric mean of 3-5% faster (в среднем геометрическом на 3–5 % быстрее).

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

Эталон не сдвинулся вовсе — 12,5 против 12,7 нс, то есть разница в пределах разброса, и общего ускорения сборки в этой паре нет. Генераторная форма тоже входит в with, поэтому вторым эталоном быть не может: её 3,1 % — смесь вклада сборки и вклада изменения байт-кода. А форма с классом подешевела на 31,7 %. Приписать эти тридцать два процента сборке нечему: эталон, измеренный тем же процессом в тех же кругах, остался на месте. Причина видна в байт-коде: на 3.13 вход в with — это одна инструкция BEFORE_WITH, на 3.14 её нет вовсе, а вместо неё стоят обычные загрузки и вызов:

3.13:  CALL 0 / BEFORE_WITH / STORE_NAME x

3.14:  CALL 0 / COPY 1 / LOAD_SPECIAL __exit__ / SWAP 2 / SWAP 3
       / LOAD_SPECIAL __enter__ / CALL 0 / STORE_NAME x

Инструкций стало больше, а времени — меньше. Мотив изменения записан в CPython gh-120507, и он не про скорость: they are bulky and won't optimize well in tier 2. Instead, we should lower them to attribute lookups and calls which can then be optimized (они громоздки и плохо оптимизируются на втором уровне. Вместо этого их следует свести к поиску атрибутов и вызовам, которые уже поддаются оптимизации). Ускорение здесь — следствие, а не цель, и никакого числа ни в задаче, ни в документации не обещано.

У перестановки есть видимый побочный эффект. На 3.14 __exit__ загружается первым, и об этом сообщают ошибки:

Последняя строка — не опечатка: когда нет обоих методов, 3.14 называет __exit__, потому что до __enter__ дело не доходит.

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

Чем измерено

Наблюдения этой статьи открываются отсюда — вместе с записью прогона:

• bench/context-managers/bytecode.py
• bench/context-managers/cost.py
• bench/context-managers/generator_cm.py
• bench/context-managers/protocol.py
• bench/context-managers/silent.py
• bench/context-managers/suppress.py
• bench/context-managers/traps.py
• bench/ctxmgr-async/exceptiongroup_suppress.py
• bench/ctxmgr-async/exitstack.py
• bench/ctxmgr-async/async_protocol.py
• bench/ctxmgr-async/what_changed_312.py

Последние четыре времени не меряют вовсе: они печатают поведение на четырёх интерпретаторах — 3.11.15, 3.12.3, 3.13.7 и 3.14.7 — и различия между ними.

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

Короткий ответ: with — это гарантия того, что выход из блока будет обработан, чем бы блок ни кончился. Протокол — два метода на типе: __enter__ вызывается на входе, __exit__ на выходе, и as связывает то, что вернул __enter__, а не сам объект.

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

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

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

Второе — сказать, что после успешного входа __exit__ решает не только «убрать за собой»: судьбу летящего исключения определяет истинность того, что он вернул. Поэтому return True в __exit__ означает не «мы всё убрали успешно», а «исключения больше нет», — и глушит любое исключение, а не только ожидаемое. Отсюда и тихая потеря данных: suppress вокруг цикла вместо suppress вокруг строки даёт 100 вместо 175, и в журнале при этом ни одного исключения.

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

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

Практика

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

from contextlib import suppress

ROWS = [
  {"id": 1, "amount": "100"},
  {"id": 2, "amount": "no data"},
  {"id": 3, "amount": "50"},
  {"id": 4, "amount": "25"},
]

total = 0
added = []
with suppress(ValueError):
  for row in ROWS:
      total += int(row["amount"])
      added.append(row["id"])

print(total)
print(added)

100
[1]

175
[1, 3, 4]

100
[1, 3, 4]

175
[1, 2, 3, 4]

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