[譯]PEP 380--子生成器的語法_ZenDei技術網路在線

導語： PEP（Python增強提案）幾乎是 Python 社區中最重要的文檔，它們提供了公告信息、指導流程、新功能的設計及使用說明等內容。對於學習者來說，PEP 是非常值得一讀的第一手材料，學習中遇到的大部分難題，都能在 PEP 中找到答案或者解決思路。我翻譯了幾篇 PEP，這麼做的目的一方面是 ...

導語： 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 。