Python 3中的yield from语法详解

前言

最近在捣鼓Autobahn，它有给出个例子是基于asyncio 的，想着说放到pypy3上跑跑看竟然就……失败了。 pip install asyncio直接报invalid syntax，粗看还以为2to3处理的时 候有问题——这不能怪我，好～多package都是用2写了然后转成3的——结果发 现asyncio本来就只支持3.3+的版本，才又回头看代码，赫然发现一句 yield from；yield我知道，但是yield from是神马？

PEP-380

好吧这个标题是我google出来的，yield from的前世今生都在 这个PEP里面，总之大意是原本的yield语句只能将CPU控制权 还给直接调用者，当你想要将一个generator或者coroutine里带有 yield语句的逻辑重构到另一个generator（原文是subgenerator） 里的时候，会非常麻烦，因为外面的generator要负责为里面的 generator做消息传递；所以某人有个想法是让python把消息传递 封装起来，使其对程序猿透明，于是就有了yield from。

PEP-380规定了yield from的语义，或者说嵌套的generator应该 有的行为模式。

假设A函数中有这样一个语句

yield from B()

B()返回的是一个可迭代（iterable）的对象b，那么A()会返回一个 generator——照我们的命名规范，名字叫a——那么：

b迭代产生的每个值都直接传递给a的调用者。 所有通过send方法发送到a的值都被直接传递给b. 如果发送的 值是None，则调用b的__next__()方法，否则调用b的send 方法。如果对b的方法调用产生StopIteration异常，a会继续 执行yield from后面的语句，而其他异常则会传播到a中，导 致a在执行yield from的时候抛出异常。 如果有除GeneratorExit以外的异常被throw到a中的话，该异常 会被直接throw到b中。如果b的throw方法抛出StopIteration， a会继续执行；其他异常则会导致a也抛出异常。 如果一个GeneratorExit异常被throw到a中，或者a的close 方法被调用了，并且b也有close方法的话，b的close方法也 会被调用。如果b的这个方法抛出了异常，则会导致a也抛出异常。 反之，如果b成功close掉了，a也会抛出异常，但是是特定的  GeneratorExit异常。 a中yield from表达式的求值结果是b迭代结束时抛出的  StopIteration异常的第一个参数。 b中的return <expr>语句实际上会抛出StopIteration(<expr>) 异常，所以b中return的值会成为a中yield from表达式的返回值。

为神马会有这么多要求？因为generator这种东西的行为在加入throw 方法之后变得非常复杂，特别是几个generator在一起的情况，需要 类似进程管理的元语对其进行操作。上面的所有要求都是为了统一 generator原本就复杂的行为，自然简单不下来啦。