[譯]PEP 380--子生成器的語法

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

我翻譯了幾篇 PEP，這麼做的目的一方面是爲了加強學習，另一方面也是爲了鍛鍊自己的英文水平。Python 與 English，都是如此重要。翻譯能將兩者巧妙地結合起來，真是一舉兩得。

本文介紹了子生成器的語法，即 yield from 語法。其它與生成器相關的 PEP 有 3 篇，翻譯的結果附在了本文末尾。若有對翻譯感興趣的同學，可在 Github 上關注下我創建的項目 peps-cn 。

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

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 實現的升級版本。

參考資料

[1] https://mail.python.org/pipermail/python-dev/2011-June/112010.html

[2] http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/

[3] http://bugs.python.org/issue11682

版權

本文檔已經放置在公共領域。源文檔：

https://github.com/python/pep...

-------------（譯文完）-------------

相關鏈接：

PEP背景知識 ：學習Python，怎能不懂點PEP呢？

PEP翻譯計劃 ：https://github.com/chinesehua...

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

[[譯] PEP 342--增強型生成器：協程](https://mp.weixin.qq.com/s/M7...

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

公衆號【Python貓】，專注Python技術、數據科學和深度學習，力圖創造一個有趣又有用的學習分享平臺。本號連載優質的系列文章，有喵星哲學貓系列、Python進階系列、好書推薦系列、優質英文推薦與翻譯等等，歡迎關注哦。PS：後臺回覆“愛學習”，免費獲得一份學習大禮包。

[譯]PEP 380--子生成器的語法

目錄

摘要

PEP接受

動機

提議

StopIteration的增強功能

正式的語義

基本原理

重構原則

結束方式

作爲線程的生成器

語法

優化

使用StopIteration來返回值

被拒絕的建議

批評

可選的提案

附加材料

參考資料

版權

ziw2pdf

apisix~helm方式的部署到k8s

firmeye - IoT固件漏洞挖掘工具

Python 潮流週刊#49：谷歌裁員 Python 團隊，微軟開源 MS-DOS 4.0

Python 潮流週刊#48：Python 3.14 的發佈計劃

Python 潮流週刊#47：當你的老師希望你去做開源

xxx，一個神奇的 Python 庫

正則表達式中 “$” 並不是表示 “字符串結束

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結