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的使用，都会出现类似的问题。所以这里显然有一个真实的问题需要解决，而异步代码日益突出的重要性使得它变得越来越紧迫。

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__本身能够yield。所以，要么我们需要在__asuspend__内部递归调用__asuspend__，要么我们需要放弃并允许这些yield发生而不调用suspend回调；无论哪种方式都违背了其目的。

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

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

1. 添加普通的__suspend__和__resume__方法。
2. 暂时保留异步上下文管理器，直到我们积累更多经验。

两者都似乎合理，因此出于懒惰 / YAGNI，本PEP暂时建议选择选项（2）。

参考资料

版权

本文档已置于公共领域。