[譯]PEP 342--增強型生成器：協程

PEP原文 ： https://www.python.org/dev/pe...

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 開發者就能夠使用生成器函數來實現協程與其它的協作式多任務。這些方法和調整是：

1. 重定義 yield 爲表達式（expression），而不是語句（statement）。當前的 yield 語句將變成一個 yield 表達式，其值將被丟棄。每當通過正常的 next() 調用來恢復生成器時，yield 表達式的返回值是 None。
2. 爲生成器（generator-iterator）添加一個新的 send() 方法，它會恢復生成器，並且 send 一個值作爲當前表達式的結果。send() 方法返回的是生成器產生的 next 值，若生成器沒有產生值就退出的話，則拋出 StopIteration 。
3. 爲生成器（generator-iterator）添加一個新的 throw() 方法，它在生成器暫停處拋出異常，並返回生成器產生的下一個值，若生成器沒有產生值就退出的話，則拋出 StopIteration （如果生成器沒有捕獲傳入的異常，或者它引發了其它異常，則該異常會傳遞給調用者。）
4. 爲生成器（generator-iterator）添加一個新的 close() 方法，它在生成器暫停處引發 GeneratorExit 。如果生成器在之後引發 StopIteration （通過正常退出，或者已經被關閉）或 GeneratorExit （通過不捕獲異常），則 close() 返回給其調用者。如果生成器產生一個值，則拋出 RuntimeError。如果生成器引發任何其它異常，也會傳遞給調用者。如果生成器已經退出（異常退出或正常退出），則 close() 不執行任何操作。
5. 增加了支持，確保即使在生成器被垃圾回收時，也會調用 close()。
6. 允許 yield 在 try-finally 塊中使用，因爲現在允許在 finally 語句中執行垃圾回收或顯式地調用 close() 。

實現了所有這些變更的原型補丁已經可用了，可作爲當前 Python CVS HEAD 的 SourceForge 補丁。# 1223381

設計規格：將值發送進生成器

新的生成器方法：send(value)

爲生成器提出了一種新的方法，即 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

定義了一個新的標準異常 GeneratorExit，繼承自 Exception。生成器應該繼續拋出它（或者就不捕獲它），或者通過拋出 StopIteration 來處理這個問題。

新的生成器方法：close()

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 也反映了這種喜好的解決方案。

1. 當生成器產生另一個值作爲對“GeneratorExit”異常的響應時，close()應該引發什麼異常？

   我最初選擇了 TypeError ，因爲它表示生成器函數發生了嚴重的錯誤行爲，應該通過修改代碼來修復。但是 PEP-343 中的 with_template 裝飾器類使用了 RuntimeError 來進行類似處理。可以說它們都應該使用相同的異常。我寧願不爲此目的引入新的異常類，因爲它不是我希望人們捕獲的異常：我希望它變成一個 traceback 給程序員看到，然後進行修復。所以我覺得它們都應該拋出 RuntimeError 。有一些先例：在檢測到無限遞歸的情況下，或者檢測到未初始化的對象（由於各種各樣的原因），核心 Python 代碼會拋出該異常。

2. Oren Tirosh 建議將 send() 方法重命名爲 feed() ，以便能跟 consumer 接口兼容（規範參見：http://effbot.org/zone/consumer.htm）。

   然而，仔細觀察 consumer 接口，似乎 feed() 所需的語義與 send() 不同，因爲後者不能在剛啓動的生成器上作有意義的調用。此外，當前定義的 consumer 接口不包含對 StopIteration 的處理。

   因此，創建一個貼合 consumer 接口的簡單的裝飾器，來裝飾生成器函數，似乎會更有用。舉個例子，它可以用初始的 next() 調用給生成器預熱（warm up），追蹤 StopIteration，甚至可以通過重新調用生成器來提供 reset() 用途。

示例

1. 一個簡單的 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

1. 一個使用 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()

1. 一個簡單的協程調度器或蹦牀（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)

1. 一個簡單的 echo 服務器以及用蹦牀原理實現的運行代碼（假設存在 nonblocking_read 、nonblocking_write 和其它 I/O 協程，該例子在連接關閉時拋出 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/chinesehua...

[[譯] PEP 255--簡單的生成器](https://mp.weixin.qq.com/s/vj...

[[譯]PEP 525--異步生成器](https://mp.weixin.qq.com/s/fy...

花下貓語： 嘮叨幾句吧，年前這幾周事情太多了，擠着時間好歹是又翻譯出一篇 PEP。與生成器密切相關的 PEP 已經完成 3/4，年後再譯最後一篇（PEP-380）。當初翻譯第一篇，完全是一時興起，直覺這是一件有意義的事，現在呢，這個念頭開始有點膨脹——我竟然在 Github 上建了個翻譯項目。我深知，自己水平實在有限，因此不求得到多少認同吧。但行好事，莫問前程。不過，若有人幫着吆喝一聲，也是極好的。

-----------------

本文原創並首發於微信公衆號【Python貓】，後臺回覆“愛學習”，免費獲得20+本精選電子書。