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

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

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

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

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

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

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

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

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

ExitStack хранит зарегистрированные контексты и вызывает их методы выхода в порядке, обратном регистрации. Метод enter_context сначала вызывает __enter__, а затем регистрирует соответствующий __exit__; поэтому ресурс, который не смог войти в контекст, не считается успешно приобретённым.

from contextlib import ExitStack

paths = ["a.txt", "b.txt"]

with ExitStack() as stack:
    files = [stack.enter_context(open(path)) for path in paths]
    data = [file.read() for file in files]

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

Для фиксированного набора ресурсов обычный with обычно лучше читается. ExitStack полезнее при динамическом количестве ресурсов, условном подключении контекстов и необходимости передать управление очисткой другому участку программы.

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

У ExitStack есть и операция pop_all: она позволяет перенести накопленные операции выхода в другой стек и тем самым разделить момент приобретения ресурсов и момент окончательной передачи ответственности за их очистку.

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

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

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

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

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

1. Вопрос: В какой последовательности ExitStack закрывает несколько зарегистрированных контекстов?

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

2. Вопрос: Что произойдёт, если очередной ресурс не смог выполнить enter внутри ExitStack?

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

3. Вопрос: Зачем нужен pop_all, если ExitStack и так закрывает ресурсы при выходе?

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