yield

PEP-380yield语句只能将CPU控制权 还给直接调用者，当你想要将一个generator或者coroutine里带有 yield语句的逻辑重构到另一个generator（原文是subgenerator） 里的时候，会非常麻烦，因为外面的generator要负责为里面的 generator做消息传递；所以某人有个想法是让python把消息传递 封装起来，使其对程序猿透明，于是就有了yield from

假设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语句实际上会抛出StopIteration() 异常，所以b中return的值会成为a中yield from表达式的返回值。

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