PEP原文 ： https://www.python.org/dev/peps/pep-0342/
PEP标題： Coroutines via Enhanced Generators
PEP作者： Guido van Rossum, Phillip J. Eby
建立日期： 2005-05-10
合入版本： 2.5
譯者 ：豌豆花下貓（Python貓 公衆号作者）
目錄
- 簡介
- 動機
- 規格摘要
- 規格：将值發送到生成器
- 新的生成器方法：send(value)
- 新的文法：yield 表達式
- 規格：異常和清理
- 新文法：yield 允許在
try-finally
- 新的生成器方法：throw（type，value = None，traceback = None）
- 新的标準異常：GeneratorExit
- 新的生成器方法：close()
- 新的生成器方法：
del()
- 可選的擴充
- 擴充的 continue 表達式
- 未決問題
- 示例
- 參考實作
- 緻謝
- 參考文獻
- 版權
這個 PEP 在生成器的 API 和文法方面，提出了一些增強功能，使得它們可以作為簡單的協程使用。這基本上是将下述兩個 PEP 的想法結合起來，如果它被采納，那它們就是多餘的了：
- PEP-288，關于生成器的屬性特征與異常（Attributes and Exceptions）。目前 PEP 沿用了它的下半部分，即生成器的異常（事實上，throw() 的方法名就取自 PEP-288）。PEP-342 用 yield 表達式（這個概念來自 PEP-288 的早期版本）來替換了生成器的屬性特征。
- PEP-325，生成器支援釋放資源。PEP-342 收緊了 PEP-325 中的一些松散的規範，使其更适用于實際的實作。
（譯注：PEP-288 和 PEP-325 都沒有被采納通過，它們的核心内容被內建到了 PEP-342裡。）
協程是表達許多算法的自然方式，例如模拟/仿真、遊戲、異步 I/O、以及其它事件驅動程式設計或協同的多任務處理。Python 的生成器函數幾乎就是協程——但不完全是——因為它們允許暫停來生成值，但又不允許在程式恢複時傳入值或異常。它們也不允許在 try-finally 結構的 try 部分作暫停，是以很難令一個異常退出的（aborted）協程來清理自己。
同樣地，當其它函數在執行時，生成器不能提供控制，除非這些函數本身是生成器，并且外部生成器之是以寫了去 yield，是要為了響應内部生成器所 yield 的值。這使得即使是相對簡單的實作（如異步通信）也變得複雜，因為調用任意函數，要麼需要生成器變堵塞（block，即無法提供控制），要麼必須在每個要調用的函數的周圍，添加一大堆引用循環代碼（a lot of boilerplate looping code）。
但是，如果有可能在生成器挂起的點上傳遞進來值或者異常，那麼，一個簡單的協程排程器或蹦床函數（
trampoline function
）就能使協程互相調用且不用阻塞——對異步應用程式有巨大好處。這些應用程式可以編寫協程來運作非阻塞的 socket I/O，通過給 I/O 排程器提供控制，直到資料被發送或變為可用。同時，執行 I/O 的代碼隻需像如下方式操作，就能暫停執行，直到 nonblocking_read() 繼續産生一個值：
data = (yield nonblocking_read(my_socket, nbytes))
換句話說， 通過給語言和生成器類型增加一些相對較小的增強，Python 不需要為整個程式編寫一系列回調，就能支援異步操作，并且對于本該需要數百上千個協作式的多任務僞線程的（co-operatively multitasking pseudothreads）程式，也可以不需要使用資源密集型線程。是以，這些增強功能将給标準 Python 帶來 Stackless Python 的許多優點，又無需對 CPython 核心及其 API 進行任何重大的修改。此外，這些增強在任何已經支援生成器的 Python 實作（例如 Jython）上都是可落實的。
通過給生成器類型增加一些簡單的方法，以及兩個微小的文法調整，Python 開發者就能夠使用生成器函數來實作協程與其它的協作式多任務。這些方法和調整是：
- 重定義 yield 為表達式（expression），而不是語句（statement）。目前的 yield 語句将變成一個 yield 表達式，其值将被丢棄。每當通過正常的 next() 調用來恢複生成器時，yield 表達式的傳回值是 None。
- 為生成器（generator-iterator）添加一個新的 send() 方法，它會恢複生成器，并且 send 一個值作為目前表達式的結果。send() 方法傳回的是生成器産生的 next 值，若生成器沒有産生值就退出的話，則抛出
StopIteration
- 為生成器（generator-iterator）添加一個新的 throw() 方法，它在生成器暫停處抛出異常，并傳回生成器産生的下一個值，若生成器沒有産生值就退出的話，則抛出
StopIteration
- 為生成器（generator-iterator）添加一個新的 close() 方法，它在生成器暫停處引發
GeneratorExit
StopIteration
GeneratorExit
RuntimeError
- 增加了支援，確定即使在生成器被垃圾回收時，也會調用 close()。
- 允許 yield 在 try-finally 塊中使用，因為現在允許在 finally 語句中執行垃圾回收或顯式地調用 close() 。
實作了所有這些變更的原型更新檔已經可用了，可作為目前 Python CVS HEAD 的 SourceForge 更新檔。# 1223381
設計規格：将值發送進生成器
為生成器提出了一種新的方法，即 send() 。它隻接收一個參數，并将它發送給生成器。調用 send(None) 完全等同于調用生成器的 next() 方法。使用其它參數調用 send() 也有同樣的效果，不同的是，目前生成器表達式産生的值會不一樣。
因為生成器在生成器函數體的頭部執行，是以在剛剛建立生成器時不會有 yield 表達式來接收值，是以，當生成器剛啟動時，禁止使用非 None 參數來調用 send() ，如果調用了，就會抛出
TypeError
（可能是由于某種邏輯錯誤）。是以，在與協程通信前，必須先調用 next() 或 send(None) ，來将程式推進到第一個 yield 表達式。
與 next() 方法一樣，send() 方法也傳回生成器産生的下一個值，或者抛出
StopIteration
異常（當生成器正常退出，或早已退出時）。如果生成器出現未捕獲的異常，則它會傳給調用者。
新文法：yield 表達式
yield 語句（yield-statement）可以被用在指派表達式的右側；在這種情況下，它就是 yield 表達式（yield-expression）。除非使用非 None 參數調用 send() ，否則 yield 表達式的值就是 None。見下文。
yield 表達式必須始終用括号括起來，除非它是作為頂級表達式而出現在指派表達式的右側。是以，下面例子都是合法的：
x = yield 42
x = yield
x = 12 + (yield 42)
x = 12 + (yield)
foo(yield 42)
foo(yield)
而下面的例子則是非法的（舉了一些特例的原因是，目前的
yield 12,42
是合法的）：
x = 12 + yield 42
x = 12 + yield
foo(yield 42, 12)
foo(yield, 12)
請注意，如今沒有表達式的 yield-語句 和 yield-表達式是合法的。這意味着：當 next() 調用中的資訊流被反轉時，應該可以在不傳遞顯式的值的情況下 yield （yield 當然就等同于 yield None）。
當調用 send(value) 時，它恢複的 yield 表達式将傳回傳入的值。當調用 next() 時，它恢複的 yield 表達式将傳回 None。如果 yield-表達式（yield-expression）是一個 yield-語句（yield-statement），其傳回值會被忽略，就類似于忽略用作語句的函數的傳回值。
實際上，yield 表達式就像一個反函數調用（inverted function）；它所 yield 的值實際上是目前函數傳回（生成）的，而它 return 的值則是通過 send() 傳入的參數。
提示：這樣的拓展文法，使得它非常地接近于 Ruby。這是故意的。請注意，Python 在阻塞時，通過使用 send(EXPR) 而不是 return EXPR 來傳值給生成器，并且在生成器與阻塞之間傳遞控制權的底層機制完全不同。Python 中的阻塞不會被編譯成 thunk，相反，yield 暫停生成器的執行進度。有一些不是這樣的特例，在 Python 中，你不能儲存阻塞以供後續調用，并且你無法測試是否存在着阻塞。（XXX - 關于阻塞的這些東西似乎不合适，或許 Guido 會編輯下，做澄清。）
設計規格：異常和清理
讓生成器對象成為通過調用生成器函數而生成的疊代器。本節中的 g 指的都是生成器對象。
新文法：yield 允許在 try-finally 裡
生成器函數的文法被拓展了，允許在 try-finally 語句中使用 yield 語句。
新的生成器方法：throw(type，value = None，traceback = None)
g.throw(type, value, traceback)
會使生成器在挂起的點處抛出指定的異常（即在 yield 語句中，或在其函數體的頭部、且還未調用 next() 時）。如果生成器捕獲了異常，并生成了新的值，則它就是 g.throw() 的傳回值。如果生成器沒有捕獲異常，那 throw() 也會抛出同樣的異常（它溜走了）。如果生成器抛出其它異常（包括傳回時産生的 StopIteration），那該異常會被 throw() 抛出。總之，throw() 的行為類似于 next() 或 send()，除了它是在挂起點處抛出異常。如果生成器已經處于關閉狀态，throw() 隻會抛出經過它的異常，而不去執行生成器的任何代碼。
抛出異常的效果完全像它所聲明的那樣：
raise type, value, traceback
會在暫停點執行。type 參數不能是 None，且 type 與 value 的類型必須得相容。如果 value 不是 type 的執行個體（instance），則按照 raise 語句建立異常執行個體的規則，用 value 來生成新的異常執行個體。如果提供了 traceback 參數，則它必須是有效的 Python 堆棧（traceback）對象，否則會抛出 TypeError 。
注釋：選擇 throw() 這個名稱，有幾個原因。Raise 是一個關鍵字，是以不能作為方法的名稱。與 raise 不同（它在執行點處即時地抛出異常），throw() 首先恢複生成器，然後才抛出異常。單詞 throw 意味着将異常抛在别處，并且跟其它語言相關聯。
考慮了幾個替代的方法名：
resolve()
,
signal()
genraise()
raiseinto()
和
flush()
。沒有一個像 throw() 那般合适。
定義了一個新的标準異常 GeneratorExit，繼承自 Exception。生成器應該繼續抛出它（或者就不捕獲它），或者通過抛出 StopIteration 來處理這個問題。
g.close() 由以下僞代碼定義：
def close(self):
try:
self.throw(GeneratorExit)
except (GeneratorExit, StopIteration):
pass
else:
raise RuntimeError("generator ignored GeneratorExit")
# Other exceptions are not caught
新的生成器方法：`del()`
g.__ del __()
是 g.close() 的裝飾器。當生成器對象被作垃圾回收時，會調用它（在 CPython 中，則是它的引用計數變為零時）。如果 close() 引發異常， 異常的堆棧資訊（traceback）會被列印到 sys.stderr 并被忽略掉；它不會退回到觸發垃圾回收的地方。這與類執行個體在處理
__del__()
的異常時的方法一樣。
如果生成器對象被循環引用，則可能不會調用
g.__del__()
。這是目前 CPython 的垃圾收集器的表現。做此限制的原因是，GC 代碼需要在一個任意點打破循環，以便回收它，在此之後，不允許 Python 代碼“看到”形成循環的對象，因為它們可能處于無效的狀态。被用于解開（hanging off）循環的對象不受此限制。
盡管實際上不太可能看到生成器被循環引用。但是，若将生成器對象存儲在全局變量中，則會通過生成器架構的 f_globals 指針建立一個循環。另外，若在資料結構中存儲對生成器對象的引用，且該資料結構被作為參數傳遞給生成器，這也會創造一個循環引用（例如，如果一個對象具有一個作為生成器的方法，并持有由該方法建立的運作中的疊代器的引用）。鑒于生成器的典型用法，這些情況都不太可能。
此外，CPython 在實作目前 PEP 時，每當由于錯誤或正常退出而終止執行時，會釋放被生成器使用的架構對象（frame object）。這保證了那些無法被恢複的生成器不會成為無法回收的循環引用的部分。這就允許了其它代碼在 try-finally 或 with 語句中使用 close() （參考 PEP-343），確定了給定的生成器會正确地完結。
可選擴充
擴充的 continue 語句
本 PEP 的早期草案提出了一種新的 continue EXPR 文法，用于 for 循環（繼承自 PEP-340），将 EXPR 的值傳給被周遊的疊代器。此功能暫時被撤銷了，因為本 PEP 的範圍已經縮小，隻關注将值傳給生成器疊代器（generator-iterator），而非其它類型的疊代器。Python-Dev 郵件清單中的一些人也覺得為這個特定功能添加新文法是為時過早（would be premature at best）。
Python-Dev 郵件的讨論提出了一些未決的問題。我羅列于此，附上我推薦的解決方案與它的動機。目前編寫的 PEP 也反映了這種喜好的解決方案。
- 當生成器産生另一個值作為對“GeneratorExit”異常的響應時，
close()
應該引發什麼異常？
我最初選擇了 TypeError ，因為它表示生成器函數發生了嚴重的錯誤行為，應該通過修改代碼來修複。但是 PEP-343 中的
with_template
-
Oren Tirosh 建議将 send() 方法重命名為 feed() ，以便能跟 consumer 接口相容（規範參見：http://effbot.org/zone/consumer.htm）。
然而，仔細觀察 consumer 接口，似乎 feed() 所需的語義與 send() 不同，因為後者不能在剛啟動的生成器上作有意義的調用。此外，目前定義的 consumer 接口不包含對 StopIteration 的處理。
是以，建立一個貼合 consumer 接口的簡單的裝飾器，來裝飾生成器函數，似乎會更有用。舉個例子，它可以用初始的 next() 調用給生成器預熱（warm up），追蹤 StopIteration，甚至可以通過重新調用生成器來提供 reset() 用途。
- 一個簡單的 consumer 裝飾器，它使生成器函數在最初調用時，就自動地前進到第一個 yield 點：
def consumer(func):
def wrapper(*args,**kw):
gen = func(*args, **kw)
gen.next()
return gen
wrapper.__name__ = func.__name__
wrapper.__dict__ = func.__dict__
wrapper.__doc__ = func.__doc__
return wrapper
- 一個使用 consumer 裝飾器建立反向生成器（reverse generator）的示例，該生成器接收圖像并建立縮略圖，再發送給其它 consumer。像這樣的函數可以連結在一起，形成 consumer 間的高效處理流水線，且每個流水線都可以具有複雜的内部狀态：
@consumer
def thumbnail_pager(pagesize, thumbsize, destination):
while True:
page = new_image(pagesize)
rows, columns = pagesize / thumbsize
pending = False
try:
for row in xrange(rows):
for column in xrange(columns):
thumb = create_thumbnail((yield), thumbsize)
page.write(
thumb, col*thumbsize.x, row*thumbsize.y )
pending = True
except GeneratorExit:
# close() was called, so flush any pending output
if pending:
destination.send(page)
# then close the downstream consumer, and exit
destination.close()
return
else:
# we finished a page full of thumbnails, so send it
# downstream and keep on looping
destination.send(page)
@consumer
def jpeg_writer(dirname):
fileno = 1
while True:
filename = os.path.join(dirname,"page%04d.jpg" % fileno)
write_jpeg((yield), filename)
fileno += 1
# Put them together to make a function that makes thumbnail
# pages from a list of images and other parameters.
#
def write_thumbnails(pagesize, thumbsize, images, output_dir):
pipeline = thumbnail_pager(
pagesize, thumbsize, jpeg_writer(output_dir)
)
for image in images:
pipeline.send(image)
pipeline.close()
- 一個簡單的協程排程器或蹦床（trampoline），它允許協程通過 yield 其它協程，來調用後者。被調用的協程所産生的非生成器的值，會被傳回給調用方的協程。類似地，如果被調用的協程抛出異常，該異常也會傳導給調用者。實際上，隻要你用 yield 表達式來調用協程（否則會阻塞），這個例子就模拟了 Stackless Python 中使用的簡單的子任務（tasklet）。這隻是一個非常簡單的例子，但也可以使用更複雜的排程程式。（例如，現有的 GTasklet 架構 (http://www.gnome.org/~gjc/gtasklet/gtasklets.html) 和 peak.events 架構 (http://peak.telecommunity.com/) 已經實作類似的排程功能，但大多數因為無法将值或異常傳給生成器，而必須使用很尴尬的解決方法。）
import collections
class Trampoline:
"""Manage communications between coroutines"""
running = False
def __init__(self):
self.queue = collections.deque()
def add(self, coroutine):
"""Request that a coroutine be executed"""
self.schedule(coroutine)
def run(self):
result = None
self.running = True
try:
while self.running and self.queue:
func = self.queue.popleft()
result = func()
return result
finally:
self.running = False
def stop(self):
self.running = False
def schedule(self, coroutine, stack=(), val=None, *exc):
def resume():
value = val
try:
if exc:
value = coroutine.throw(value,*exc)
else:
value = coroutine.send(value)
except:
if stack:
# send the error back to the "caller"
self.schedule(
stack[0], stack[1], *sys.exc_info()
)
else:
# Nothing left in this pseudothread to
# handle it, let it propagate to the
# run loop
raise
if isinstance(value, types.GeneratorType):
# Yielded to a specific coroutine, push the
# current one on the stack, and call the new
# one with no args
self.schedule(value, (coroutine,stack))
elif stack:
# Yielded a result, pop the stack and send the
# value to the caller
self.schedule(stack[0], stack[1], value)
# else: this pseudothread has ended
self.queue.append(resume)
- 一個簡單的 echo 伺服器以及用蹦床原理實作的運作代碼（假設存在
nonblocking_read
nonblocking_write
ConnectionLost
# coroutine function that echos data back on a connected
# socket
#
def echo_handler(sock):
while True:
try:
data = yield nonblocking_read(sock)
yield nonblocking_write(sock, data)
except ConnectionLost:
pass # exit normally if connection lost
# coroutine function that listens for connections on a
# socket, and then launches a service "handler" coroutine
# to service the connection
#
def listen_on(trampoline, sock, handler):
while True:
# get the next incoming connection
connected_socket = yield nonblocking_accept(sock)
# start another coroutine to handle the connection
trampoline.add( handler(connected_socket) )
# Create a scheduler to manage all our coroutines
t = Trampoline()
# Create a coroutine instance to run the echo_handler on
# incoming connections
#
server = listen_on(
t, listening_socket("localhost","echo"), echo_handler
)
# Add the coroutine to the scheduler
t.add(server)
# loop forever, accepting connections and servicing them
# "in parallel"
#
t.run()
實作了本 PEP 中描述的所有功能的原型更新檔已經可用，參見 SourceForge 更新檔 1223381 （https://bugs.python.org/issue1223381）。
該更新檔已送出到 CVS，2005年8月 01-02。
Raymond Hettinger (PEP 288) 與 Samuele Pedroni (PEP 325) 第一個正式地提出将值或異常傳遞給生成器的想法，以及關閉生成器的能力。Timothy Delaney 建議了本 PEP 的标題，還有 Steven Bethard 幫忙編輯了早期的版本。另見 PEP-340 的緻謝部分。
TBD.
本文檔已經放置在公共領域。
源文檔：https://github.com/python/peps/blob/master/pep-0342.txt
----------------（譯文完）--------------------
相關連結：
PEP背景知識 ：學習Python，怎能不懂點PEP呢？
PEP翻譯計劃 ：https://github.com/chinesehuazhou/peps-cn
[譯] PEP 255--簡單的生成器
[譯]PEP 525--異步生成器
花下貓語： 唠叨幾句吧，年前這幾周事情太多了，擠着時間好歹是又翻譯出一篇 PEP。與生成器密切相關的 PEP 已經完成 3/4，年後再譯最後一篇（PEP-380）。當初翻譯第一篇，完全是一時興起，直覺這是一件有意義的事，現在呢，這個念頭開始有點膨脹——我竟然在 Github 上建了個翻譯項目。我深知，自己水準實在有限，是以不求得到多少認同吧。但行好事，莫問前程。不過，若有人幫着吆喝一聲，也是極好的。
-----------------
本文原創并首發于微信公衆号【Python貓】，背景回複“愛學習”，免費獲得20+本精選電子書。
![TestLink導出用例轉換工具(XML2Excel)[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)