有人可以解釋PEP 0492: Coroutines with async and await syntax中概述的新語法?會有什麼樣新的python異步和等待關鍵字
def do_nothing():
return
和
async def do_nothing():
return
有人可以解釋PEP 0492: Coroutines with async and await syntax中概述的新語法?會有什麼樣新的python異步和等待關鍵字
def do_nothing():
return
和
async def do_nothing():
return
一言以蔽之的東西之間的主要區別,因爲這是一個廣泛的話題:
@asyncio.coroutine
def foo():
bar = yield from some_async_func()
print(bar)
asyncio.get_event_loop().run_until_complete(foo())
此使用ASYNCIO模塊定義了一個協程。 foo
是一個協程,它調用協程some_async_func
(因爲它調用異步函數,它本身也必須是異步的)。這整個裝置需要在事件循環中異步運行。
對foo()
的調用會產生一個生成器對象,事件循環會一直運行,直到它不再生成任何東西。 yield from
掛起函數併產生到其他協程,它基本上以相同的方式執行(發生器,直到完成等等)。當該發生器完成後,該值將被返回並分配給bar
並且該功能被解凍。
這簡直就是異步編程。
PEP 0492要改善這種編程在某些特定方面的支持:
- 提議作出協同程序Python中的適當獨立的概念[..]
- 這是容易將協程與常規發生器相混淆,因爲它們共享相同的語法[..]
- 函數是否是協程由其正文中的語句產出或產出決定,這會導致不明顯的錯誤[..]
其中產量在語法上允許,限制的句法特徵的有用- 支持異步調用僅限於表達[..]要說
這些點是協程是一個相當獨特的東西,但都不是很與語言中的其他內容區別開來,因爲它們主要是劫持已經存在的生成器語法。 PEP希望通過使協程和異步編程成爲更易於使用的獨立事物來改進這一點。
- 本提案引入了新的語法和語義來增強Python中的協同支持。
- 以下新的語法來聲明一個本機協同程序[..]
只是促進協同程序到本地類型應該是一個明顯的改善。它允許你像任何其他類型一樣檢測協同程序。它也統一實施。目前有一個用於協同程序的「本地」asyncio
模塊,但也有像Twisted這樣的第三方庫,它們有自己的語法和用於協程的裝飾器。
- 這PEP假定異步任務由一個事件循環調度和協調[..]雖然PEP不依賴於任何特定的事件循環執行[..]
這就是說你將能夠使用一種定義的語法來編寫協程,但是使用你想要的任何兼容的事件循環實現來執行它們。
您可以在PEP本身閱讀的其他建議。
我認爲該PEP的抽象和理論基礎是可以理解的。他們怎麼樣,你不明白?一般來說,你是否理解*協程/異步編程*,還是我們需要從那裏開始? – deceze
你使用過Python 3.4的'asyncio'模塊嗎?通過查看現有的3.4代碼和相應的3.5代碼,可以更容易理解'async' /'await'。 (在PEP中引用的python-ideas和python-dev線程中有一些消息包含了這種比較的鏈接;我希望其中一個人已經進入了PEP本身,但是......) – abarnert
也許這會有所幫助。我從來沒有使用異步編程本身,但我有一些想法是什麼。也許只是這個語法替換的純Python中的一個最小工作示例就是我所希望的。 –