摘要

Python 允许 with 和 async with 语句在单个语句中处理多个上下文管理器，只要它们分别是同步或异步的。当同步和异步上下文管理器混合时，开发者必须使用深度嵌套的语句或使用有风险的变通方案，例如过度使用 AsyncExitStack。

因此，我们建议允许 with 语句在单个语句中同时接受同步和异步上下文管理器，方法是使用 async 关键字来标记单独的异步上下文管理器。

此更改消除了不必要的嵌套，提高了代码可读性，并在不降低异步代码显式性的情况下改善了人体工程学。

动机

现代 Python 应用程序经常需要通过同步和异步上下文管理器的混合来获取多个资源。虽然全同步或全异步情况下允许单个语句包含多个上下文管理器，但两者的混合会导致“末日阶梯”

async def process_data():
    async with acquire_lock() as lock:
        with temp_directory() as tmpdir:
            async with connect_to_db(cache=tmpdir) as db:
                with open('config.json', encoding='utf-8') as f:
                    # We're now 16 spaces deep before any actual logic
                    config = json.load(f)
                    await db.execute(config['query'])
                    # ... more processing

这种过度的缩进阻碍了上下文管理器的使用，尽管它们具有理想的语义。请参阅“被拒绝的想法”部分，了解当前的变通方案及其缺点。

有了这个 PEP，函数可以这样写

async def process_data():
    with (
        async acquire_lock() as lock,
        temp_directory() as tmpdir,
        async connect_to_db(cache=tmpdir) as db,
        open('config.json', encoding='utf-8') as f,
    ):
        config = json.load(f)
        await db.execute(config['query'])
        # ... more processing

这种紧凑的替代方案避免了在同步和异步上下文管理器之间每次切换时强制进行新的缩进级别。同时，它只使用现有的关键字，甚至比我们当前的语法更精确地使用 async 关键字来区分异步代码。

我们不建议废弃 async with 语句，并且确实主张它继续用于单行语句，以便“async”是每个打开异步上下文管理器的行的第一个非空白标记。

尽管如此，我们的提案允许 with async some_ctx()，重视一致的语法设计，而不是强制执行单一的代码风格，我们预计这将由风格指南、linter、格式化程序等处理。有关进一步讨论，请参见此处。

基本原理

混合同步/异步上下文管理器在现代 Python 应用程序中很常见，例如异步数据库连接或 API 客户端以及同步文件操作。当前的语法强制开发者在深度嵌套的代码或容易出错的变通方案（如 AsyncExitStack）之间做出选择。

这个 PEP 通过基于现有模式的最小语法更改来解决这个问题。通过允许使用 async 标记单个上下文管理器，我们保持了 Python 对异步代码的显式方法，同时消除了不必要的嵌套。

作为语法糖的实现确保了零运行时开销——新语法解糖为开发者今天编写的相同嵌套 with 和 async with 语句。这种方法不需要新的协议，不需要更改现有上下文管理器，也不需要理解新的运行时行为。

规范

with (..., async ...): 语法解糖为一系列上下文管理器，与当前的多上下文 with 语句相同，只是带有 async 关键字前缀的那些使用 __aenter__ / __aexit__ 协议。

仅修改 with 语句；async with async ctx(): 是语法错误。

ast.withitem 节点获得一个新的 is_async 整型属性，遵循 ast.comprehension 上的现有 is_async 属性。对于 async with 语句项，此属性始终为 1。对于常规 with 语句中的项，当 async 关键字存在时，此属性为 1，否则为 0。这使得 AST 能够精确地表示哪些上下文管理器应该使用异步协议，同时保持与现有 AST 处理工具的向后兼容性。

向后兼容性

此更改完全向后兼容：唯一可观察到的区别是以前引发 SyntaxError 的某些语法现在可以成功执行。

实现上下文管理器的库（标准库和第三方库）无需修改即可与新语法配合使用。直接处理源代码的库和工具需要进行少量更新，就像任何新语法一样。

如何教授此内容

我们建议在 async with 之后立即或同时引入“混合上下文管理器”。例如，教程可能涵盖：

1. 基本上下文管理器：从单个 with 语句开始
2. 多个上下文管理器：显示当前的逗号语法
3. 异步上下文管理器：引入 async with
4. 混合上下文：“用 async 标记每个异步上下文管理器”

被拒绝的想法

@contextmanager
async def as_acm(sync_cm):
    with sync_cm as result:
        await sleep(0)
        yield result

async with (
    acquire_lock(),
    as_acm(open('file')) as f,
):
    ...

async with contextlib.AsyncExitStack() as stack:
    await stack.enter_async_context(acquire_lock())
    f = stack.enter_context(open('file', encoding='utf-8'))
    ...

async with multicontext(
    acquire_lock(),
    open('file'),
) as (f, _):
    ...

# Rejected approach
async with (
    acquire_lock(),
    open('config.json') as f,  # actually sync, surprise!
):
    ...

with (
    sync_context() as foo,
    async a_context() as bar,
): ...

with (
    sync_context() as foo,
    async a_context()
): ...

with (
    # sync_context() as foo,
    async a_context()
): ...

with (async a_context()): ...

with async a_context(): ...

致谢

感谢 Rob Rolls 提出 with async。还要感谢在 PyCon 2025 sprints、Discourse 和工作中与我们讨论这个问题和可能解决方案的许多其他人。

版权

本文档置于公共领域或 CC0-1.0-Universal 许可证下，以更宽松者为准。