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

Обычный контекстный менеджер реализует синхронный протокол __enter__ и __exit__, а асинхронный блок требует методы __aenter__ и __aexit__. Поэтому объект только с синхронными методами не поддерживает протокол асинхронного контекстного менеджера и не может быть использован напрямую через async with.

Асинхронный протокол нужен не из-за самого факта работы внутри корутины, а потому, что вход и выход из контекста могут приостанавливать выполнение через await.

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

Асинхронные контекстные менеджеры появились вместе с моделью async/await, стандартизированной в Python 3.5 в рамках PEP 492. Обычный with был рассчитан на операции, которые выполняются синхронно: открытие файла, захват блокировки или освобождение ресурса не должны приостанавливать текущий код через await.

Для сетевых соединений, асинхронных блокировок и транзакций в неблокирующем драйвере потребовался отдельный протокол. Он позволяет выполнить асинхронную инициализацию ресурса и асинхронное освобождение без блокировки event loop.

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

Если асинхронный ресурс обернуть обычным контекстным менеджером, его методы не смогут корректно ожидать сетевую операцию или другую корутину. Попытка использовать такой объект в async with завершается ошибкой поддержки асинхронного протокола, а простая замена async with на with может привести к блокировке event loop.

Особенно опасен случай, когда синхронный метод внутри контекста выполняет длительный ввод-вывод. Формально код будет работать, но все другие задачи этого event loop будут ждать завершения блокирующей операции.

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

При выполнении async with Python ищет у типа объекта специальные методы __aenter__ и __aexit__. Результат каждого из них должен быть ожидаемым объектом: Python ожидает результат __aenter__ перед выполнением тела блока, а __aexit__ — при выходе из него.

Минимальный пример:

class Connection:
    async def __aenter__(self):
        await self.open()
        return self

    async def __aexit__(self, exc_type, exc, tb):
        await self.close()
        return False

    async def open(self):
        pass

    async def close(self):
        pass

async def work():
    async with Connection() as connection:
        await connection.request()

async with концептуально выполняет асинхронный вход, затем тело блока, а после этого асинхронный выход. Если в теле возникло исключение, __aexit__ получает его тип, значение и traceback; возвращаемое значение True подавляет исключение, а False или None позволяет ему продолжить распространение.

with и async with не являются взаимозаменяемыми. Если объект реализует оба протокола, выбор определяется самой конструкцией: with использует __enter__ и __exit__, а async with — __aenter__ и __aexit__. Автоматического перехода с одного протокола на другой нет.

Асинхронный контекстный менеджер не обязан возвращать из __aenter__ самого себя. Он может вернуть отдельный объект, например асинхронную сессию; переменная после as получит именно этот результат.

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

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

Обычный менеджер отвергли, потому что драйвер возвращает корутины, а синхронное ожидание блокировало бы event loop. Ручное управление также не выбрали: при исключениях и отмене задачи легко забыть откат или закрытие соединения.

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

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

Что произойдёт, если объект реализует одновременно __enter__/__exit__ и __aenter__/__aexit__?

Протоколы независимы. Конструкция with вызовет синхронные методы, а async with — асинхронные. Python не выбирает протокол по наличию await внутри окружающей функции и не использует запасной вариант, если предпочтительный набор методов отсутствует.
Делает ли async with синхронную блокирующую операцию неблокирующей?

Нет. Асинхронность контекстного менеджера определяется тем, что его методы возвращают ожидаемые результаты, но обычный блокирующий вызов внутри __aenter__, __aexit__ или тела блока всё равно блокирует поток event loop.

Для синхронного ресурса обычно выбирают специальный асинхронный адаптер, выносят блокирующую операцию в поток через подходящий механизм запуска или используют её только вне критичного event loop. Само добавление async def не превращает блокирующий вызов в неблокирующий.
Что нужно учитывать при отмене задачи во время __aexit__?

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

Нельзя бездумно подавлять все исключения из __aexit__: это может скрыть как ошибку очистки, так и исходную причину сбоя. Политика должна явно определять, какие исключения допустимо подавлять, а какие нужно передавать вызывающему коду.