資訊專欄INFORMATION COLUMN
摘要：輔之以事件循環(huán)，協(xié)程可用于異步處理，尤其是在中。當前支持的協(xié)程基于增強型生成器，于版本開始采用。新的特性中，異步還有兩種新用途異步內容管理器和迭代器。
現(xiàn)在 Python 已經支持用協(xié)程進行異步處理。但最近有建議稱添加協(xié)程以全面完善 Python 的語言結構，而不是像現(xiàn)在這樣把他們作為生成器的一個類型。此外，兩個新的關鍵字———異步(async)和等待(await)，都該添加到 Python 中來支持協(xié)程。
也許有人不太了解協(xié)程，其實協(xié)程的原理很簡單，打個比方就能講明白了：假設有十個人去食堂打飯，這個食堂比較窮，只有一個打飯窗口和一個打飯阿姨，那么打飯就只能一個一個排隊進行。這十個人胃口很大，每個人都要點5個菜，但這十個人都喜歡猶豫不決，點菜的時候每點一個菜后再想下一個菜點什么，因此后面的人等得很著急呀。
這樣一直站著也不是個事兒，所以打菜的阿姨看到某人猶豫5秒后就會吼一聲，讓他排到隊伍末尾，讓別人先打菜，等輪到他的時候他也差不多想好吃什么了。這確實是個不錯的方法，但也有一個缺點，那就是打菜的阿姨會等每個人5秒鐘，如果那個人在5秒內沒有做出決定吃啥，其實這5秒就浪費了。一個人點一個菜就是浪費5秒，十個人每個人點5個菜可就浪費的多啦「菜都涼了要」。
那怎么辦呢？阿姨又發(fā)話了：大家都是學生，學生就要自覺，我以后也不主動讓你們排到末尾了，如果你們覺得自己會猶豫不決，就主動點直接點一個菜就站后面去，等下次排到的時候也差不多想好吃啥了。
這個方法果然有效，大家點了菜后想的第一件事情不是下一個菜吃什么，而是自己會不會猶豫，如果會猶豫那直接排到隊伍后面去，如果不會就接著點菜。這樣一來整個隊伍的效率自然就高了。
這個例子里，排隊阿姨的那聲吼就是我們的 CPU 中斷，用于切換上下文。每個打飯的學生就是一個 task。而每個人決定自己要不要讓出窗口的這種行為，其實就是我們協(xié)程的核心思想。
OK，回到主題，協(xié)程就是一種可以在代碼的各種預定義位置暫停和恢復執(zhí)行的函數，它避免了無意義的調度，由此提高代碼性能。而子程序是一種特殊的協(xié)同程序，它只有單一入口，通過回調來完成執(zhí)行。Python 的協(xié)程「現(xiàn)有的以生成器為基礎的協(xié)程和新提出的協(xié)程」不是一般意義上的協(xié)程，因為在執(zhí)行暫停時它們只能將控制權轉給調用者，而不是像常見的那樣將控制權轉給別的協(xié)程。輔之以事件循環(huán)，協(xié)程可用于異步處理，尤其是在 I / O 中。
Python 當前支持的協(xié)程基于 PEP342 增強型生成器，于 Python 2.5 版本開始采用。該 PEP 將 yield 語句改為表達式，并為生成器增加了一些新的方法 「 send() , throw() , and close() 」 ，同時確保 close() 方法在生成器進入垃圾回收階段時得到調用。該功能在 Python 3.3 版本的 PEP 380 中得到進一步增強，它通過增加 yield 表達式，允許生成器將部分功能授予另一個生成器「即子生成器」。
以上方法都使協(xié)程依賴于生成器，這使得在代碼段何處進行異步調用變得令人困惑，且頗受限制。尤其，with 和 for 聲明在理論上可以將協(xié)程用于異步調用，但 Python 語法在那些位置不允許使用 yield 表達式，因此無法進行異步調用。此外，如果協(xié)程的重構將 yield 或 yield from 從函數中移除 ，它就不再被視為協(xié)程，這會導致一些不明顯的錯誤； asyncio 模塊通過 @asyncio.coroutine 裝飾器來彌補這方面的不足。
PEP 492 旨在解決以上所有問題。其想法源于 Yury Selivanov 在四月中旬提出的 python-ideas 郵件列表，該想法受到很多人熱情追捧。在5月5日，Guido van Rossum 同意將它添加在 Python 3.5 版本中。不僅如此，5月12日就得到執(zhí)行。一切都進展迅速，盡管最終該方法還是在 python-idea 和 python-dev 方面引起熱情討論。
從語法角度看，變化相當簡單：
async def read_data(db):
data = await db.fetch("SELECT ...")
...
這個例子「來源于 PEP」將使用新的 async def 構造函數創(chuàng)建一個 read_data() 協(xié)程。 await 表達式將暫停執(zhí)行 read_data()，直到 db.fetch() await able 完成并返回其結果。await 類似于 yeild from ，但它會確保其參數 awaitable。
此外還有幾種不同類型的 awaitable。一種是本地的協(xié)程對象，在調用本地協(xié)同程序后的返回為 awaitable，還有基于生成器且有 @types.coroutine 裝飾的協(xié)程。還有一種是未來對象，它代表著在未來完成的操作，也是 awaitable。__await __()方法在 awaitable 的對象都會出現(xiàn)。
然而，向一種語言添加新的關鍵字時會出現(xiàn)這樣的問題：任何與關鍵字名字相同的變量都會成為語法錯誤。為了避免該問題，Python 3.5 和 3.6 版本將 “softly deprecate “ 「溫柔棄用」 async 和 await 為變量名，而不將他們當做語法錯誤。解析器會跟蹤 async def 塊，并將塊內的關鍵字區(qū)別對待，從而使現(xiàn)有的使用繼續(xù)有效。
新的特性中，異步還有兩種新用途：異步內容管理器(with)和迭代器(for)。在協(xié)程里，這兩種構造函數的示例如下：
async def commit(session, data):
...
async with session.transaction():
...
await session.update(data)
...
...
async for row in Cursor():
print(row)
異步內容管理器必須實現(xiàn)兩個異步方法，__aenter __()和__aexit __()，他們都返回 awaitables；異步迭代器須實現(xiàn)__aiter __()和__anext __()。這些方法都是現(xiàn)有的同步內容管理器和迭代器的異步版本。
此前主要的討論是延期執(zhí)行的 “cofunction” 功能 PEP 3152 是否會是更好的起點，該 PEP 的作者 Greg Ewing 提出了此問題。但有很多人認為 Selivanov 提議的語法更適合 codef，cocall ，也有人更加贊同 Ewing 的提議。這樣來來回回的爭論了很多次。有一些人認為cofunction 的語法在處理某些情況時相當復雜并且不符合 Python 語言的特性。后來 Van Rossum 總結了 cofunctions 語法存在的問題，并拒絕采納該方法。
此外，還有幾點關于附加異步功能的建議值得討論，但并不緊急。對于關鍵詞的討論有些本末倒置。 await 的優(yōu)先級問題也討論了一段時間，結果是，不同于 yeild 和 yeild from 僅有最低優(yōu)先級，await 具有較高的優(yōu)先級。
但 Mark Shannon 抱怨說，實現(xiàn) Selivanov 的建議并不需要增加新的語法。其他人也提出了類似的意見，但 Selivanov 或其他支持者并未對此提出反駁。關鍵在于簡化協(xié)同程序的編寫。除此之外，Van Rossum 希望協(xié)同程序暫停的位置能夠顯而易見，查看代碼就能發(fā)現(xiàn)：
新的語法才是 PEP 存在的意義。我希望通過句法結構就能判斷出協(xié)程的懸停點。
在兩三周后，發(fā)布了多個版本的 PEP ，引起了諸多辯論。Selivanov 耐心地解釋他的想法，并根據反饋意見不斷修正自己的想法。異步協(xié)程特性對 Python 語言的未來很可能至關重要，整個探索過程都很快，很順遂。不過，Python 開發(fā)者們將這些想法付諸實踐很可能還需要一段時間。
原文地址：Python coroutines with async and await
參考文章: 對Python中yield和協(xié)程的理解
本文系 OneAPM 工程師編譯整理。想閱讀更多技術文章，請訪問 OneAPM 官方博客。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://www.ezyhdfw.cn/yun/37579.html
摘要：創(chuàng)建第一個協(xié)程推薦使用語法來聲明協(xié)程，來編寫異步應用程序。協(xié)程兩個緊密相關的概念是協(xié)程函數通過定義的函數協(xié)程對象調用協(xié)程函數返回的對象。它是一個低層級的可等待對象，表示一個異步操作的最終結果。 我們講以Python 3.7 上的asyncio為例講解如何使用Python的異步IO。 showImg(https://segmentfault.com/img/remote/14600000...
摘要：所以與多線程相比，線程的數量越多，協(xié)程性能的優(yōu)勢越明顯。值得一提的是，在此過程中，只有一個線程在執(zhí)行，因此這與多線程的概念是不一樣的。 真正有知識的人的成長過程，就像麥穗的成長過程：麥穗空的時候，麥子長得很快，麥穗驕傲地高高昂起，但是，麥穗成熟飽滿時，它們開始謙虛，垂下麥芒。 ——蒙田《蒙田隨筆全集》 上篇論述了關于python多線程是否是雞肋的問題，得到了一些網友的認可，當然也有...
摘要：上一篇文章第一章異步及協(xié)程基礎第二節(jié)關鍵字下一篇文章第二章實戰(zhàn)演練開發(fā)網站第一節(jié)網站結構使用協(xié)程可以開發(fā)出類似同步代碼的異步行為。協(xié)程函數可以通過以下三張方式調用在本身是協(xié)程的函數內通過關鍵字調用。 上一篇文章：Python：Tornado 第一章：異步及協(xié)程基礎：第二節(jié)：Python關鍵字yield下一篇文章：Python：Tornado 第二章：實戰(zhàn)演練：開發(fā)Tornado網站：第...
摘要：事件循環(huán)是異步編程的底層基石。對事件集合進行輪詢，調用回調函數等一輪事件循環(huán)結束，循環(huán)往復。協(xié)程直接利用代碼的執(zhí)行位置來表示狀態(tài)，而回調則是維護了一堆數據結構來處理狀態(tài)。時代的協(xié)程技術主要是，另一個比較小眾。 Coding Crush Python開發(fā)工程師 主要負責豈安科技業(yè)務風險情報系統(tǒng)redq。 引言 1.1. 存儲器山 存儲器山是 Randal Bryant 在《深入...
摘要：具有以下基本同步原語子進程提供了通過創(chuàng)建和管理子進程的。雖然隊列不是線程安全的，但它們被設計為專門用于代碼。表示異步操作的最終結果。 Python的asyncio是使用 async/await 語法編寫并發(fā)代碼的標準庫。通過上一節(jié)的講解，我們了解了它不斷變化的發(fā)展歷史。到了Python最新穩(wěn)定版 3.7 這個版本，asyncio又做了比較大的調整，把這個庫的API分為了 高層級API和...
閱讀 5126·2023-04-25 18:47
閱讀 2745·2021-11-19 11:33
閱讀 3494·2021-11-11 16:54
閱讀 3155·2021-10-26 09:50
閱讀 2620·2021-10-14 09:43
閱讀 737·2021-09-03 10:47
閱讀 737·2019-08-30 15:54
閱讀 1564·2019-08-30 15:44
