PEP 撤回

已撤回，取而代之的是 PEP 567。

摘要

虽然我们通常尽量避免使用全局状态，但仍然存在一些情况，大家一致认为使用全局状态是最佳方法。在 Python 中，处理此类情况的标准模式是将全局状态存储在全局或线程本地存储中，然后使用 with 块将对该全局状态的修改限制到单个动态作用域。使用此模式的示例包括标准库的 warnings.catch_warnings 和 decimal.localcontext、NumPy 的 numpy.errstate（它公开 IEEE 754 浮点数标准提供的错误处理设置）以及许多服务器应用程序框架中日志记录上下文或 HTTP 请求上下文的处理。

但是，在编写生成器或协程时，目前没有符合人体工程学的方式来管理对全局状态的此类局部更改。例如，以下代码

def f():
    with warnings.catch_warnings():
        for x in g():
            yield x

可能会也可能不会成功捕获由 g() 引发的警告，并且可能会也可能不会无意中吞并代码其他地方触发的警告。上下文管理器旨在仅应用于 f 及其被调用者，最终其动态作用域包含了其调用者任意且不可预测的部分。在编写异步代码时，这个问题变得尤其严重，因为本质上所有函数都变成了协程。

在这里，我们建议通过在执行在上下文管理器作用域内挂起或恢复时通知上下文管理器来解决此问题，从而允许它们适当地限制其影响。

规范

上下文管理器协议中添加了两种新的可选方法：__suspend__ 和 __resume__。如果存在，这些方法将在框架的执行在 with 块的上下文中挂起或恢复时被调用。

更正式地说，考虑以下代码

with EXPR as VAR:
    PARTIAL-BLOCK-1
    f((yield foo))
    PARTIAL-BLOCK-2

目前这等效于以下代码（从 PEP 343 复制）

mgr = (EXPR)
exit = type(mgr).__exit__  # Not calling it yet
value = type(mgr).__enter__(mgr)
exc = True
try:
    try:
        VAR = value  # Only if "as VAR" is present
        PARTIAL-BLOCK-1
        f((yield foo))
        PARTIAL-BLOCK-2
    except:
        exc = False
        if not exit(mgr, *sys.exc_info()):
            raise
finally:
    if exc:
        exit(mgr, None, None, None)

本 PEP 提出修改 with 块处理，使其变为

mgr = (EXPR)
exit = type(mgr).__exit__  # Not calling it yet
### --- NEW STUFF ---
if the_block_contains_yield_points:  # known statically at compile time
    suspend = getattr(type(mgr), "__suspend__", lambda: None)
    resume = getattr(type(mgr), "__resume__", lambda: None)
### --- END OF NEW STUFF ---
value = type(mgr).__enter__(mgr)
exc = True
try:
    try:
        VAR = value  # Only if "as VAR" is present
        PARTIAL-BLOCK-1
        ### --- NEW STUFF ---
        suspend(mgr)
        tmp = yield foo
        resume(mgr)
        f(tmp)
        ### --- END OF NEW STUFF ---
        PARTIAL-BLOCK-2
    except:
        exc = False
        if not exit(mgr, *sys.exc_info()):
            raise
finally:
    if exc:
        exit(mgr, None, None, None)

类似的挂起/恢复调用也围绕嵌入在 yield from、await、async with 和 async for 构造中的 yield 点进行包装。

def f():
    with OUTER:
        with INNER:
            yield VALUE

INNER.__suspend__()
OUTER.__suspend__()
yield VALUE
OUTER.__resume__()
INNER.__resume__()

def f():
    with OUTER:
        yield from g()

def g():
    with INNER
        yield VALUE

基本原理

在摘要中，我们给出了一个看似合理但错误的代码示例

def f():
    with warnings.catch_warnings():
        for x in g():
            yield x

为了在当前的 Python 中使其正确，我们需要改写类似以下内容

def f():
    with warnings.catch_warnings():
        it = iter(g())
    while True:
        with warnings.catch_warnings():
            try:
                x = next(it)
            except StopIteration:
                break
        yield x

另一方面，如果本 PEP 被接受，则原始代码将按原样变得正确。或者，如果这没有说服力，那么这里还有一个损坏的代码示例；修复它需要更大的调整，这些调整留作读者的练习

async def test_foo_emits_warning():
    with warnings.catch_warnings(record=True) as w:
        await foo()
    assert len(w) == 1
    assert "xyzzy" in w[0].message

并且请注意，最后一个示例一点也不人为——这正是您编写测试以确保使用 async/await 的协程正确引发警告的方式。对于几乎任何使用 warnings.catch_warnings、decimal.localcontext 或 numpy.errstate 的 async/await 代码，都会出现类似的问题。因此，这里显然需要解决一个真正的问题，并且异步代码的日益突出使得这个问题变得越来越紧迫。

with warnings.catch_warnings():
    loop.call_soon(f)

向后兼容性

因为 __suspend__ 和 __resume__ 是可选的，并且默认为无操作，所以所有现有的上下文管理器都将继续像以前一样工作。

在速度方面，此提议在进入 with 块时增加了额外的开销（我们现在必须检查其他方法；CPython 中的属性查找失败相当慢，因为它涉及分配 AttributeError），以及在挂起点增加了额外的开销。由于 with 块和挂起点的所在位置是静态已知的，因此编译器可以简单地优化掉所有情况下的此开销，除了实际上在 with 内部有 yield 的情况。此外，因为我们只在 with 块的开头对 __suspend__ 和 __resume__ 执行一次属性检查，当这些属性未定义时，每次 yield 的开销可以优化为单个 C 级别的 if (frame->needs_suspend_resume_calls) { ... }。因此，我们预计总体开销可以忽略不计。

与 PEP 492 的交互

PEP 492 添加了新的异步上下文管理器，它们类似于常规的上下文管理器，但不同于常规方法__enter__和__exit__，它们具有协程方法__aenter__和__aexit__。

遵循此模式，人们可能会期望此提案添加__asuspend__和__aresume__协程方法。但这没有多大意义，因为关键在于__suspend__应该在我们让出执行线程并允许其他代码运行之前被调用。将__asuspend__设为协程唯一能实现的就是让__asuspend__本身能够让出。因此，我们需要在__asuspend__内部递归调用__asuspend__，或者放弃并允许这些让出发生而无需调用挂起回调；无论哪种方式，它都会违背整个目的。

好吧，除了一个例外：协程代码的一种可能的模式是调用yield来与协程运行器通信，但实际上并没有挂起它们的执行（即，协程可能知道协程运行器将在处理完yield的消息后立即恢复它们）。一个例子是curio.timeout_after异步上下文管理器，它向curio内核发送一个特殊的set_timeout消息，然后内核立即（同步地）恢复发送该消息的协程。从用户的角度来看，此超时值的行为就像激发此PEP的全局变量一样。但是，有一个关键的区别：这种异步上下文管理器，从定义上讲，与协程运行器紧密集成。因此，协程运行器可以承担跟踪哪些超时适用于哪些协程的责任，而根本不需要此PEP（这确实是curio.timeout_after的工作方式）。

这留下了两种处理异步上下文管理器的合理方法

1. 添加普通的__suspend__和__resume__方法。
2. 暂时先不要管异步上下文管理器，直到我们对它们有更多经验。

两种方法似乎都有道理，所以出于懒惰/YAGNI，此PEP暂时建议坚持选择(2)。

参考文献

版权

本文档已置于公共领域。