我正打算寫寫 Python 的生成器，然而查資料時發現，引入生成器的 PEP 沒人翻譯過，因此就花了點時間翻譯出來。如果在閱讀時，你有讀不懂的地方，不用懷疑，極有可能是我譯得不到位。若出現這種情況，我建議你直接閱讀原文，最好也能將錯誤處告知於我，以便做出修改。
原文：www.python.org/dev/peps/pe…
建立日期：2001-05-18
合入Python版本：2.2
譯者 ：豌豆花下貓（Python貓 公眾號作者）
PEP背景知識 ：學習Python，怎能不懂點PEP呢？
摘要
這個 PEP 想在 Python 中引入生成器的概念，以及一個新的表示式，即 yield 表示式。
動機
當一個生產者函式在處理某些艱難的任務時，它可能需要維持住生產完某個值時的狀態，大多數程式語言都提供不了既舒服又高效的方案，除了往引數列表中新增回撥函式，然後每生產一個值時就去呼叫一下。
例如，標準庫中的tokenize.py採用這種方法：呼叫者必須傳一個 tokeneater 函式給 tokenize() ，當 tokenize() 找到下一個 token 時再呼叫。這使得 tokenize 能以自然的方式編碼，但程式呼叫 tokenize 會變得極其複雜，因為它需要記住每次回撥前最後出現的是哪個 token(s)。tabnanny.py中的 tokeneater 函式是處理得比較好的例子，它在全域性變數中維護了一個狀態機，用於記錄已出現的 token 和預期會出現的 token 。這很難正確地工作，而且也挺難讓人理解。不幸的是，它已經是最標準的解決方法了。
有一個替代方案是一次性生成 Python 程式的全部解析，並存入超大列表中。這樣 tokenize 客戶端可以用自然的方式，即使用區域性變數和區域性控制流（例如迴圈和巢狀的 if 語句），來跟蹤其狀態。然而這並不實用：程式會變得臃腫，因此不能在實現整個解析所需的記憶體上放置先驗限制；而有些 tokenize 客戶端僅僅想要檢視某個特定的東西是否曾出現（例如，future 宣告，或者像 IDLE 做的那樣，只是首個縮排的宣告），因此解析整個程式就是嚴重地浪費時間。
另一個替代方案是把 tokenize 變為一個迭代器【註釋1】，每次呼叫它的 next() 方法時再傳遞下一個 token。這對呼叫者來說很便利，就像前一方案把結果存入大列表一樣，同時沒有記憶體與“想要早點退出怎麼辦”的缺點。然而，這個方案也把 tokenize 的負擔轉化成記住 next() 的呼叫狀態，讀者只要瞄一眼 tokenize.tokenize_loop() ，就會意識到這是一件多麼可怕的苦差事。或者想象一下，用遞迴演算法來生成普通樹結構的節點：若把它投射成一個迭代器框架實現，就需要手動地移除遞迴狀態並維護遍歷的狀態。
第四種選擇是在不同的執行緒中執行生產者和消費者。這允許兩者以自然的方式維護其狀態，所以都會很舒服。實際上，Python 原始碼發行版中的 Demo/threads/Generator.py 就提供了一個可用的同步通訊（synchronized-communication）類，來完成一般的任務。但是，這在沒有執行緒的平臺上無法運用，而且就算可用也會很慢（與不用執行緒可取得的成就相比）。
最後一個選擇是使用 Python 的變種 Stackless 【註釋2-3】來實現，它支援輕量級的協程。它與前述的執行緒方案有相同的程式設計優勢，效率還更高。然而，Stackless 在 Python 核心層存在爭議，Jython 也可能不會實現相同的語義。這個 PEP 不是討論這些問題的地方，但完全可以說生成器是 Stackless 相關功能的子集在當前 CPython 中的一種簡單實現，而且可以說，其它 Python 實現起來也相對簡單。
以上分析完了已有的方案。其它一些高階語言也提供了不錯的解決方案，特別是 Sather 的迭代器，它受到 CLU 的迭代器啟發【註釋4】；Icon 的生成器，一種新穎的語言，其中每個表示式都是生成器【註釋5】。它們雖有差異，但基本的思路是一致的：提供一種函式，它可以返回中間結果（“下一個值”）給它的呼叫者，同時還儲存了函式的區域性狀態，以便在停止的位置恢復（譯註：resum，下文也譯作啟用）呼叫。一個非常簡單的例子：
def fib():
a, b = 0, 1
while 1:
yield b
a, b = b, a+b
複製程式碼當 fib() 首次被呼叫時，它將 a 設為 0，將 b 設為 1，然後生成 b 給其呼叫者。呼叫者得到 1。當 fib 恢復時，從它的角度來看，yield 語句實際上跟 print 語句相同：fib 繼續執行，且所有區域性狀態完好無損。然後，a 和 b 的值變為 1，並且 fib 再次迴圈到 yield，生成 1 給它的呼叫者。以此類推。 從 fib 的角度來看，它只是提供一系列結果，就像用了回撥一樣。但是從呼叫者的角度來看，fib 的呼叫就是一個可隨時恢復的可迭代物件。跟執行緒一樣，這允許兩邊以最自然的方式進行編碼；但與執行緒方法不同，這可以在所有平臺上高效完成。事實上，恢復生成器應該不比函式呼叫昂貴。
同樣的方法適用於許多生產者/消費者函式。例如，tokenize.py 可以生成下一個 token 而不是用它作為引數呼叫回撥函式，而且 tokenize 客戶端可以以自然的方式迭代 tokens：Python 生成器是一種迭代器，但是特別強大。
設計規格：yield
引入了一種新的表示式：
yield_stmt：“yield”expression_list
yield 是一個新的關鍵字，因此需要一個 future 宣告【註釋8】來進行引入：在早期版本中，若想使用生成器的模組，必須在接近頭部處包含以下行（詳見 PEP 236）：
from __future__ import generators
複製程式碼沒有引入 future 模組就使用 yield 關鍵字，將會告警。 在後續的版本中，yield 將是一個語言關鍵字，不再需要 future 語句。
yield 語句只能在函式內部使用。包含 yield 語句的函式被稱為生成器函式。從各方面來看，生成器函式都只是個普通函式，但在它的程式碼物件的 co_flags 中設定了新的“CO_GENERATOR”標誌。
當呼叫生成器函式時，實際引數還是繫結到函式的區域性變數空間，但不會執行程式碼。得到的是一個 generator-iterator 物件；這符合迭代器協議【註釋6】，因此可用於 for 迴圈。注意，在上下文無歧義的情況下，非限定名稱 “generator” 既可以指生成器函式，又可以指生成器-迭代器（generator-iterator）。
每次呼叫 generator-iterator 的 next() 方法時，才會執行 generator-function 體中的程式碼，直至遇到 yield 或 return 語句（見下文），或者直接迭代到盡頭。
如果執行到 yield 語句，則函式的狀態會被凍結，並將 expression_list 的值返回給 next() 的呼叫者。“凍結”是指掛起所有本地狀態，包括區域性變數、指令指標和內部堆疊：儲存足夠的資訊，以便在下次呼叫 next() 時，函式可以繼續執行，彷彿 yield 語句只是一次普通的外部呼叫。
限制：yield 語句不能用於 try-finally 結構的 try 子句中。困難的是不能保證生成器會被再次啟用（resum），因此無法保證 finally 語句塊會被執行；這就太違背 finally 的用處了。
限制：生成器在活躍狀態時無法被再次啟用：
>>> def g():
... i = me.next()
... yield i
>>> me = g()
>>> me.next()
Traceback (most recent call last):
...
File "<string>", line 2, in g
ValueError: generator already executing
複製程式碼設計規格：return
生成器函式還可以包含以下形式的return語句：
return
複製程式碼注意，生成器主體中的 return 語句不允許使用 expression_list （然而當然，它們可以巢狀地使用在生成器裡的非生成器函式中）。
當執行到 return 語句時，程式會正常 return，繼續執行恰當的 finally 子句（如果存在）。然後引發一個 StopIteration 異常，表明迭代器已經耗盡。如果程式沒有顯式 return 而執行到生成器的末尾，也會引發 StopIteration 異常。
請注意，對於生成器函式和非生成器函式，return 意味著“我已經完成，並且沒有任何有趣的東西可以返回”。
注意，return 並不一定會引發 StopIteration ：關鍵在於如何處理封閉的 try-except 結構。 例如：
>>> def f1():
... try:
... return
... except:
... yield 1
>>> print list(f1())
[]
複製程式碼因為，就像在任何函式中一樣，return 只是退出，但是：
>>> def f2():
... try:
... raise StopIteration
... except:
... yield 42
>>> print list(f2())
[42]
複製程式碼因為 StopIteration 被一個簡單的 except 捕獲，就像任意異常一樣。
設計規格：生成器和異常傳播
如果一個未捕獲的異常——包括但不限於 StopIteration——由生成器函式引發或傳遞，則異常會以通常的方式傳遞給呼叫者，若試圖重新啟用生成器函式的話，則會引發 StopIteration 。 換句話說，未捕獲的異常終結了生成器的使用壽命。
示例（不合語言習慣，僅作舉例）：
>>> def f():
... return 1/0
>>> def g():
... yield f() # the zero division exception propagates
... yield 42 # and we'll never get here
>>> k = g()
>>> k.next()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 2, in g
File "<stdin>", line 2, in f
ZeroDivisionError: integer division or modulo by zero
>>> k.next() # and the generator cannot be resumed
Traceback (most recent call last):
File "<stdin>", line 1, in ?
StopIteration
>>>
複製程式碼設計規格：Try/Exception/Finally
前面提過，yield 語句不能用於 try-finally 結構的 try 子句中。這帶來的結果是生成器要非常謹慎地分配關鍵的資源。但是在其它地方，yield 語句並無限制，例如 finally 子句、except 子句、或者 try-except 結構的 try 子句：
>>> def f():
... try:
... yield 1
... try:
... yield 2
... 1/0
... yield 3 # never get here
... except ZeroDivisionError:
... yield 4
... yield 5
... raise
... except:
... yield 6
... yield 7 # the "raise" above stops this
... except:
... yield 8
... yield 9
... try:
... x = 12
... finally:
... yield 10
... yield 11
>>> print list(f())
[1, 2, 4, 5, 8, 9, 10, 11]
>>>
複製程式碼示例
# 二叉樹類
class Tree:
def __init__(self, label, left=None, right=None):
self.label = label
self.left = left
self.right = right
def __repr__(self, level=0, indent=" "):
s = level*indent + `self.label`
if self.left:
s = s + "\n" + self.left.__repr__(level+1, indent)
if self.right:
s = s + "\n" + self.right.__repr__(level+1, indent)
return s
def __iter__(self):
return inorder(self)
# 從列表中建立 Tree
def tree(list):
n = len(list)
if n == 0:
return []
i = n / 2
return Tree(list[i], tree(list[:i]), tree(list[i+1:]))
# 遞迴生成器，按順序生成樹標籤
def inorder(t):
if t:
for x in inorder(t.left):
yield x
yield t.label
for x in inorder(t.right):
yield x
# 展示：建立一棵樹
t = tree("ABCDEFGHIJKLMNOPQRSTUVWXYZ")
# 按順序列印樹的節點
for x in t:
print x,
print
# 非遞迴生成器
def inorder(node):
stack = []
while node:
while node.left:
stack.append(node)
node = node.left
yield node.label
while not node.right:
try:
node = stack.pop()
except IndexError:
return
yield node.label
node = node.right
# 練習非遞迴生成器
for x in t:
print x,
print
Both output blocks display:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
複製程式碼問答
為什麼重用 def 而不用新的關鍵字？
請參閱下面的 BDFL 宣告部分。
為什麼用新的關鍵字yield而非內建函式？
Python 中通過關鍵字能更好地表達控制流，即 yield 是一個控制結構。而且為了 Jython 的高效實現，編譯器需要在編譯時就確定潛在的掛起點，新的關鍵字會使這一點變得簡單。CPython 的實現也大量利用它來檢測哪些函式是生成器函式（儘管一個新的關鍵字替代 def 就能解決 CPython 的問題，但人們問“為什麼要新的關鍵字”問題時，並不想要新的關鍵字）。
為什麼不是其它不帶新關鍵字的特殊語法？
例如，為何不用下面用法而用 yield 3：
return 3 and continue
return and continue 3
return generating 3
continue return 3
return >> , 3
from generator return 3
return >> 3
return << 3
>> 3
<< 3
* 3
複製程式碼我沒有錯過一個“眼色”吧？在數百條訊息中，我算了每種替代方案有三條建議，然後總結出上面這些。不需要用新的關鍵字會很好，但使用 yield 會更好——我個人認為，在一堆無意義的關鍵字或運算子序列中，yield 更具表現力。儘管如此，如果這引起足夠的興趣，支持者應該發起一個提案，交給 Guido 裁斷。
為什麼允許用return，而不強制用StopIteration？
“StopIteration”的機制是底層細節，就像 Python 2.1 中的“IndexError”的機制一樣：實現時需要做一些預先定義好的東西，而 Python 為高階使用者開放了這些機制。儘管不強制要求每個人都在這個層級工作。 “return”在任何一種函式中都意味著“我已經完成”，這很容易解讀和使用。注意，return 並不總是等同於 try-except 結構中的 raise StopIteration（參見“設計規格：Return”部分）。
那為什麼不允許return一個表示式？
也許有一天會允許。 在 Icon 中，return expr 意味著“我已經完成”和“但我還有最後一個有用的值可以返回，這就是它”。 在初始階段，不強制使用return expr的情況下，使用 yield 僅僅傳遞值，這很簡單明瞭。
BDFL宣告
Issue
引入另一個新的關鍵字（比如，gen 或 generator ）來代替 def ，或以其它方式改變語法，以區分生成器函式和非生成器函式。
Con
實際上（你如何看待它們），生成器是函式，但它們具有可恢復性。使它們建立起來的機制是一個相對較小的技術問題，引入新的關鍵字無助於強調生成器是如何啟動的機制（生成器生命中至關重要卻很小的部分）。
Pro
實際上（你如何看待它們），生成器函式實際上是工廠函式，它們就像施了魔法一樣地生產生成器-迭代器。 在這方面，它們與非生成器函式完全不同，更像是建構函式而不是函式，因此重用 def 無疑是令人困惑的。藏在內部的 yield 語句不足以警示它們的語義是如此不同。
BDFL
def 留了下來。任何一方都沒有任何爭論是完全令人信服的，所以我諮詢了我的語言設計師的直覺。它告訴我 PEP 中提出的語法是完全正確的——不是太熱，也不是太冷。但是，就像希臘神話中的 Delphi（譯註：特爾斐，希臘古都） 的甲骨文一樣，它並沒有告訴我原因，所以我沒有對反對此 PEP 語法的論點進行反駁。 我能想出的最好的（除了已經同意做出的反駁）是“FUD”（譯註：縮寫自 fear、uncertainty 和 doubt）。 如果這從第一天開始就是語言的一部分，我非常懷疑這早已讓安德魯·庫奇林（Andrew Kuchling）的“Python Warts”頁面成為可能。（譯註：wart 是疣，一種難看的皮膚病。這是一個 wiki 頁面，列舉了對 Python 吹毛求疵的建議）。
參考實現
當前的實現（譯註：2001年），處於初步狀態（沒有文件，但經過充分測試，可靠），是Python 的 CVS 開發樹【註釋9】的一部分。 使用它需要您從原始碼中構建 Python。
這是衍生自 Neil Schemenauer【註釋7】的早期補丁。
腳註和參考文獻
[1] PEP-234, Iterators, Yee, Van Rossum
[3] PEP-219, Stackless Python, McMillan
[4] "Iteration Abstraction in Sather" Murer, Omohundro, Stoutamire and Szyperski
www.icsi.berkeley.edu/~sather/Pub…
[6] The concept of iterators is described in PEP 234. See [1] above.
[8] PEP 236, Back to the future, Peters
[9] To experiment with this implementation, check out Python from CVS according to the instructions at sf.net/cvs/?group_… ，Note that the std test Lib/test/test_generators.py contains many examples, including all those in this PEP.
版權資訊
本文件已經放置在公共領域。源文件：github.com/python/peps…
（譯文完）
PS：官方 PEP 有將近500個，然而保守估計，被翻譯成中文的不足20個（去重的情況下）。我好奇，感興趣將一些重要的 PEP 翻譯出來的人有多少呢？現拋此問題出來探探路，歡迎留言交流。
-----------------
本文翻譯並首發於微信公眾號【Python貓】，後臺回覆“愛學習”，免費獲得20+本精選電子書。