導語： PEP（Python增強提案）幾乎是 Python 社群中最重要的文件，它們提供了公告資訊、指導流程、新功能的設計及使用說明等內容。對於學習者來說，PEP 是非常值得一讀的第一手材料，學習中遇到的大部分難題，都能在 PEP 中找到答案或者解決思路。
我翻譯了幾篇 PEP，這麼做的目的一方面是為了加強學習，另一方面也是為了鍛鍊自己的英文水平。Python 與 English，都是如此重要。翻譯能將兩者巧妙地結合起來，真是一舉兩得。
本文介紹了子生成器的語法，即 yield from 語法。其它與生成器相關的 PEP 有 3 篇，翻譯的結果附在了本文末尾。若有對翻譯感興趣的同學，可在 Github 上關注下我建立的專案 peps-cn 。
PEP原文 ： https://www.python.org/dev/peps/pep-0380/
PEP標題： Syntax for Delegating to a Subgenerator
PEP作者： Gregory Ewing
建立日期： 2009-02-13
合入版本： 3.3
譯者 ：豌豆花下貓（Python貓 公眾號作者）
摘要
為生成器提出了一種新的語法，用於將部分的操作委派給其它的生成器。這使得一部分包含“yield”的程式碼段，可以被分離並放置到其它生成器中。與此同時，子生成器會返回一個值，交給委派生成器（delegating generator）使用。
當一個生成器再次 yield 被另一個生成器生成的值時，該語法還創造了一些最佳化的可能。
PEP接受
Guido 於 2011 年 6 月 26 日正式接受本 PEP。
動機
Python 的生成器是一種協程，但有一個限制，它只能返回值給直接的呼叫者。這意味著包含了 yield 的程式碼段不能像其它程式碼段一樣，被拆分並放入到單獨的函式中。如果做了這樣的分解，就會導致被呼叫的函式本身成為一個生成器，並且必須顯式地迭代這個生成器，以便重新 yield 它產生的所有值。
如果只關心生成值的過程，那麼可以不費勁地使用如下的迴圈：
for v in g:
yield v
但是，如果在呼叫send()，throw()和close()的情況下，要使子生成器與呼叫者正確地互動，就相當困難。如後面所說，必要的程式碼非常複雜，因此想要正確地處理所有特殊情況，將會非常棘手。
一種新的語法被提出來解決此問題。在最簡單的用例中，它等同於上面的 for-迴圈，並且可以處理生成器的所有的行為，同時還能用簡單而直接的方式進行重構。
提議
以下的新的生成器語法將被允許在生成器的內部使用：
yield from <expr>
其中 <expr> 表示式作用於可迭代物件，從迭代器中提取元素。該迭代器會遍歷到耗盡，在此期間，它直接向包含 yield from 表示式的呼叫者生成器（即“委託生成器”）生成和接收值。
此外，當該迭代器是一個生成器時，則此生成器可以執行 return 語句返回一個值，而該值將成為 yield from 表示式的值。
yield from 表示式的完整語義可透過生成器協議來描述如下：
迭代器返回的任何值都直接傳給呼叫者。
使用 send() 傳送給委託生成器的任何值都直接傳給迭代器。如果傳送的值是 None，則呼叫迭代器的
next()方法。如果傳送的值不是 None，則呼叫迭代器的 send() 方法。如果呼叫引發了 StopIteration，則恢復委託生成器。任何其它異常都會傳遞給委託生成器。除 GeneratorExit 以外，任何傳給委託生成器的異常都會傳給迭代器的 throw() 方法。如果呼叫引發 StopIteration，則恢復委託生成器。任何其它異常都會傳遞給委託生成器。
如果傳給委託生成器的是 GeneratorExit 異常，或者呼叫委託生成器的 close() 方法，則迭代器的 close() 方法會被呼叫（如果有）。如果呼叫時出現異常，則會傳給委託生成器。否則的話，在委託生成器中丟擲 GeneratorExit。
yield from 表示式的值是迭代器終止時引發的 StopIteration 異常的第一個引數。
生成器裡的 return expr 導致從生成器退出時引發 StopIteration(expr)。
StopIteration的增強功能
為方便起見，StopIteration 異常被賦予了一個 value 屬性，來儲存它的第一個引數，若無引數，則為 None。
正式的語義
本節使用 Python 3語法。
1、RESULT = yield from EXPR 語句等同於以下語句：
_i = iter(EXPR)
try:
_y = next(_i)
except StopIteration as _e:
_r = _e.value
else:
while 1:
try:
_s = yield _y
except GeneratorExit as _e:
try:
_m = _i.close
except AttributeError:
pass
else:
_m()
raise _e
except BaseException as _e:
_x = sys.exc_info()
try:
_m = _i.throw
except AttributeError:
raise _e
else:
try:
_y = _m(*_x)
except StopIteration as _e:
_r = _e.value
break
else:
try:
if _s is None:
_y = next(_i)
else:
_y = _i.send(_s)
except StopIteration as _e:
_r = _e.value
break
RESULT = _r
2、在生成器中，return value 語句在語義上等同於raise StopIteration(value)，除了一點，當前返回的生成器中的 except 子句無法捕獲該異常。
3、 StopIteration 異常的行為就像這樣定義：
class StopIteration(Exception):
def __init__(self, *args):
if len(args) > 0:
self.value = args[0]
else:
self.value = None
Exception.__init__(self, *args)
基本原理
重構原則
上面提到的大多數語義，其背後的基本原理源於一種對生成器程式碼進行重構的願望。即希望可以將包含一個或多個 yield 表示式的程式碼段，分離進一個單獨的函式中（使用常規手段來處理作用域範圍內的變數引用，等等），並透過 yield from 表示式來呼叫該函式。
在合理可行的情況下，這種複合而成的生成器的行為應該跟原始的非分離的生成器完全相同，包括呼叫 __next __() 、send()、throw() 和 close() 。
子迭代器（而非生成器）的語義被選擇成為生成器案例的合理泛化（generalization）。
所提出的語義在重構方面具有如下限制：
一個捕獲了 GenetatorExit 卻不重新丟擲的程式碼塊，不能在完全保留相同行為的情況下被分離出去。
如果將 StopIteration 異常拋進了委託生成器中，則分離的生成器的行為跟原始程式碼的行為可能會不同。
由於這些用例幾乎不存在，因此不值得為支援它們而考慮額外的複雜性。
結束方式
當在 yield from 處掛起時，並且使用 close() 方法顯式地終止委託生成器時，關於是否要一併終止子迭代器，存在一些爭議。一個反對的論據是，如果在別處存在對子迭代器的引用，這樣做會導致過早結束它。
對非引用計數型的 Python 實現的考慮，導致了應該顯式地結束的結論，以便在所有型別的 Python 實現上，顯式地結束子迭代器與非重構的迭代器，能具有相同的效果。
這裡做的假設是，在大多數用例中，子迭代器不會被共享。在子迭代器被共享的稀有情況下，可透過一個阻塞呼叫 throw() 和 close() 的裝飾器來實現，或者使用除 yield from 以外的方法來呼叫子迭代器。
作為執行緒的生成器
使生成器能夠 return 值的動機，還考慮到使用生成器來實現輕量級的執行緒。當以這種方式使用生成器時，將輕量級執行緒的計算擴散到許多函式上就會是合理的。人們希望能夠像呼叫普通函式一樣呼叫子生成器，傳遞給它引數並接收返回值。
使用提議的語法，像以下的表示式
y = f(x)
其中 f 是一個普通的函式，就可以被轉化成一個委託呼叫
y = yield from g(x)
其中 g 是生成器。透過把 g 想象成一個普通的能被 yield 語句掛起的函式，人們可以推斷出結果程式碼的行為。
當以這種方式把生成器作為執行緒使用時，通常人們不會對 yield 所傳入或傳出的值感興趣。但是，也有一些例子，執行緒可以作為 item 的生產者或消費者。yield from 表示式允許執行緒的邏輯被擴散到所需的儘可能多的函式中，item 的生產與消費發生在任意的子函式中，並且這些 item 會自動路由到/去它們的最終來源/目的地。
對於 throw() 與 close() ，可以合理地預期，如果從外部向執行緒內拋入了一個異常，那麼首先應該線上程掛起處的最內部的生成器中引發，再從那裡向外傳遞；而如果執行緒是從外部呼叫 close() 來終結的，那也應該從最內部往外地終止處於活動態的生成器鏈。
語法
所提出的特定語法被選中，像它的含義所暗示，並沒有引入任何新的關鍵詞，且清晰地突出了它與普通 yield 的不同。
最佳化
當存在一長串生成器時，使用專門的語法就為最佳化提供了可能性。這種生成器鏈可能存在，例如，當遞迴遍歷樹結構時。在鏈上傳遞 __next__() 的呼叫與 yield 返回值，可能造成 O(n) 開銷，最壞情況下會是 O(n**2)。
可能的策略是向生成器物件新增一個槽（slot）來儲存委派給它的生成器。當在生成器上呼叫 __next__() 或 send() 時，首先檢查該槽，如果非空，則它引用的生成器將會被啟用。如果引發了 StopIteration，該槽會被清空，並且主生成器會被啟用。
這將減少一系列 C 函式呼叫的委託開銷，並不涉及 Python 程式碼的執行。一種可能的增強方法是在迴圈中遍歷整個生成器鏈，並直接啟用最後一個生成器，儘管 StopIteration 的處理會比較複雜。
使用StopIteration來返回值
有多種方法可以將生成器的返回值傳回。也有一些替代的方法，例如將其儲存為生成器-迭代器物件的屬性，或將其作為子生成器的 close() 方法的呼叫值返回。然而，本 PEP 提議的機制很有吸引力，有如下理由：
使用泛化的 StopIteration 異常，可以使其它型別的迭代器輕鬆地加入協議，而不必增加額外的屬性或 close() 方法。
它簡化了實現，因為子生成器的返回值變得可用的點與引發異常的點相同。延遲到任意時間都需要在某處儲存返回值。
被拒絕的建議
一些想法被討論並且拒絕了。
建議：應該有一些方法可以避免對__next__() 的呼叫，或者用帶有指定值的 send() 呼叫來替換它，目的是支援對生成器作裝飾，以便可以自動地執行初始的 __next__() 。
決議：超出本提案的範圍。這種生成器不該與 yield from 一起使用。
建議：如果關閉一個子迭代器時，引發了帶返回值的 StopIteration 異常，則將該值從 close() 呼叫中返回給委託生成器。
此功能的動機是為了透過關閉生成器，傳訊號給傳入生成器的最後的值。被關閉的生成器會捕獲 GeneratorExit ，完成其計算並返回一個結果，該結果最終成為 close() 呼叫的返回值。
決議：close() 與 GeneratorExit 的這種用法，將與當前的退出（bail-out）與清理機制的角色不相容。這要求在關閉子生成器後、關閉一個委託生成器時，該委託生成器可以被恢復，而不是重新引發 GeneratorExit。但這是不可接受的，因為呼叫 close() 進行清理的意圖，無法保證委託生成器能正確地終止。
透過其它方式，可以更好地處理向消費者告知（signal）最後的值的問題，例如傳送一個哨兵值（sentinel value）或者拋入一個被生產者與消費者都認可的異常。然後，消費者可以檢查該哨兵或異常，透過完成其計算並正常地返回，來作響應。這種方案在存在委託的情況下表現正確。
建議：如果 close() 不返回值，如果出現 StopIteration 中帶有非 None 的值，則丟擲一個異常。
決議：沒有明確的理由如此做。忽略返回值在 Python 中的任何其它地方，都不會被視為錯誤。
批評
根據本提案，yield from 表示式的值將以跟普通 yield 表示式非常不同的方式得出。這意味著其它不包含 yield 表示式的語法可能會更合適，但到目前為止，還沒有提出可接受的替代方案。被拒絕的替代品包括 call、delegate 和 gcall。
有人提議，應該使用子生成器中除 return 以外的某些機制，來處理 yield from 表示式的返回值。但是，這會干擾將子生成器視為可掛起函式的目的，因為它不能像其它函式一樣 return 值。
有人批評，說使用異常來傳遞返回值是“濫用異常”，卻沒有任何具體的理由來證明它。無論如何，這只是一種實現的建議；其它機制可以在不丟失本提案的任何關鍵特性的情況下使用。
有人建議，使用與 StopIteration 不同的異常來返回值，例如 GeneratorReturn。但是，還沒有令人信服的實際理由被提出，並且向 StopIteration 新增 value 屬性減輕了從異常（該異常可能存在也可能不存在）中提取返回值的所有困難。此外，使用不同的異常意味著，與普通函式不同，生成器中不帶值的 return，將不等同於 return None 。
可選的提案
之前已經提到了類似的提議，有些語法使用 yield * 而不是 yield from。雖然 yield * 更簡潔，但是有爭議的是，它看起來與普通的 yield 太相似了，可能在閱讀程式碼時會忽視了其中的差異。
據作者所知，之前的提案只關注於 yield 產生值，因此遭受到了批評，即他們所替代的兩行 for 迴圈並沒有足夠令人厭煩，不足以讓人為新的語法辯護。透過處理完整的生成器協議，本提案提供了更多的好處。
附加材料
本提案的語法的一些用例已經被提供出來，並且基於上面概括的第一個最佳化的原型也已實現。
Examples and Implementation
可以從跟蹤器問題的 issue 11682 中獲得針對 Python 3.3 實現的升級版本。
參考資料
https://mail.python.org/pipermail/python-dev/2011-June/112010.html
http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/
http://bugs.python.org/issue11682
版權
本文件已經放置在公共領域。源文件：
https://github.com/python/peps/blob/master/pep-0380.txt
