前言
最近在搗鼓Autobahn,它有給出個例子是基于asyncio 的,想著說放到pypy3上跑跑看竟然就……失敗了。 pip install asyncio
直接報invalid syntax,粗看還以為2to3處理的時 候有問題——這不能怪我,好~多package都是用2寫了然后轉成3的——結果發 現asyncio本來就只支持3.3+的版本,才又回頭看代碼,赫然發現一句 yield from
;yield
我知道,但是yield from
是神馬?
PEP-380
好吧這個標題是我google出來的,yield from
的前世今生都在 這個PEP里面,總之大意是原本的yield
語句只能將CPU控制權 還給直接調用者,當你想要將一個generator或者coroutine里帶有 yield語句的邏輯重構到另一個generator(原文是subgenerator) 里的時候,會非常麻煩,因為外面的generator要負責為里面的 generator做消息傳遞;所以某人有個想法是讓python把消息傳遞 封裝起來,使其對程序猿透明,于是就有了yield from
。
PEP-380規定了yield from
的語義,或者說嵌套的generator應該 有的行為模式。
假設A函數中有這樣一個語句
yield from B()
B()
返回的是一個可迭代(iterable)的對象b,那么A()會返回一個 generator——照我們的命名規范,名字叫a——那么:
__next__()
方法,否則調用b的send 方法。如果對b的方法調用產生StopIteration異常,a會繼續 執行yield from
后面的語句,而其他異常則會傳播到a中,導 致a在執行yield from
的時候拋出異常。 如果有除GeneratorExit以外的異常被throw到a中的話,該異常 會被直接throw到b中。如果b的throw方法拋出StopIteration, a會繼續執行;其他異常則會導致a也拋出異常。 如果一個GeneratorExit異常被throw到a中,或者a的close 方法被調用了,并且b也有close方法的話,b的close方法也 會被調用。如果b的這個方法拋出了異常,則會導致a也拋出異常。 反之,如果b成功close掉了,a也會拋出異常,但是是特定的 GeneratorExit異常。 a中yield from
表達式的求值結果是b迭代結束時拋出的 StopIteration異常的第一個參數。 b中的return <expr>
語句實際上會拋出StopIteration(<expr>)
異常,所以b中return的值會成為a中yield from
表達式的返回值。為神馬會有這么多要求?因為generator這種東西的行為在加入throw 方法之后變得非常復雜,特別是幾個generator在一起的情況,需要 類似進程管理的元語對其進行操作。上面的所有要求都是為了統一 generator原本就復雜的行為,自然簡單不下來啦。
新聞熱點
疑難解答