python3中的yield from语句

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——那么：

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

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

我承认我一下没看明白PEP的作者到底想说什么，于是动手“重构” 一遍大概会有点帮助。

一个没用的例子

说没用是因为你大概不会真的想把程序写成这样，但是……反正能说明 问题就够了。

设想有这样一个generator函数：

def inner():    coef = 1    total = 0    while True:        try:            input_val = yield total            total = total + coef * input_val        except SwitchSign:            coef = -(coef)        except BreakOut:            return total

这个函数生成的generator将从send方法接收到的值累加到局部 变量total中，并且在收到BreakOut异常时停止迭代；至于另外 一个SwitchSign异常应该不难理解，这里就不剧透了。

从代码上看，由inner()函数得到的generator通过send接收用于 运算的数据，同时通过throw方法接受外部代码的控制以执行不同 的代码分支，目前为止都很清晰。

接下来因为需求有变动，我们需要在inner()这段代码的前后分别加 入初始化和清理现场的代码。鉴于我认为“没坏的代码就不要动”，我 决定让inner()维持现状，然后再写一个outer()，把添加的代码放在 outer()里，并提供与inner()一样的操作接口。由于inner()利用了 generator的若干特性，所以outer()也必须做到这五件事情：

1. outer()必须生成一个generator；
2. 在每一步的迭代中，outer()要帮助inner()返回迭代值；
3. 在每一步的迭代中，outer()要帮助inner()接收外部发送的数据；
4. 在每一步的迭代中，outer()要处理inner()接收和抛出所有异常；
5. 在outer()被close的时候，inner()也要被正确地close掉。

根据上面的要求，在只有yield的世界里，outer()可能是长这样的：

def outer1():    print("Before inner(), I do this.")    i_gen = inner()    input_val = None    ret_val = i_gen.send(input_val)    while True:        try:            input_val = yield ret_val            ret_val = i_gen.send(input_val)        except StopIteration:            break        except Exception as err:            try:                ret_val = i_gen.throw(err)            except StopIteration:                break    print("After inner(), I do that.")

WTF，这段代码比inner()本身还要长，而且还没处理close操作。

现在我们来试试外星科技：

def outer2():    print("Before inner(), I do this.")    yield from inner()    print("After inner(), I do that.")

除了完全符合上面的要求外，这四行代码打印出来的时候还能省点纸。

我们可以在outer1()和outer2()上分别测试 数据 以及 异常 的传递，不难发现这两个generator的行为基本上是一致的。既然如此， 外星科技当然在大多数情况下是首选。

简单地来理解，yeild from语法就是将生成器函数中包括yield语句的部分逻辑封装到一个子生成器函数中。然后在子生成器函数外面可以做一些其他的业务逻辑。整个生成器函数（包括子生成器函数）对外就是一个生成器函数。

学习资料转载于：

http://blog.theerrorlog.com/yield-from-in-python-3.html