异步等待的 Python 协程

Tags: python

现在 Python 已经支持用 协程 进行异步处理。但最近有建议称添加协程以全面完善 Python 的语言结构,而不是像现在这样把他们作为生成器的一个类型。此外,两个新的关键字———异步(async)和等待(await),都该添加到 Python 中来支持协程。

也许有人不太了解协程,其实协程的原理很简单,打个比方就能讲明白了:假设有十个人去食堂打饭,这个食堂比较穷,只有一个打饭窗口和一个打饭阿姨,那么打饭就只能一个一个排队进行。这十个人胃口很大,每个人都要点5个菜,但这十个人都喜欢犹豫不决,点菜的时候每点一个菜后再想下一个菜点什么,因此后面的人等得很着急呀。

这样一直站着也不是个事儿,所以打菜的阿姨看到某人犹豫5秒后就会吼一声,让他排到队伍末尾,让别人先打菜,等轮到他的时候他也差不多想好吃什么了。这确实是个不错的方法,但也有一个缺点,那就是打菜的阿姨会等每个人5秒钟,如果那个人在5秒内没有做出决定吃啥,其实这5秒就浪费了。一个人点一个菜就是浪费5秒,十个人每个人点5个菜可就浪费的多啦「菜都凉了要」。

那怎么办呢?阿姨又发话了:大家都是学生,学生就要自觉,我以后也不主动让你们排到末尾了,如果你们觉得自己会犹豫不决,就主动点直接点一个菜就站后面去,等下次排到的时候也差不多想好吃啥了。

这个方法果然有效,大家点了菜后想的第一件事情不是下一个菜吃什么,而是自己会不会犹豫,如果会犹豫那直接排到队伍后面去,如果不会就接着点菜。这样一来整个队伍的效率自然就高了。

这个例子里,排队阿姨的那声吼就是我们的 CPU 中断,用于切换上下文。每个打饭的学生就是一个 task。而每个人决定自己要不要让出窗口的这种行为,其实就是我们协程的核心思想。

OK,回到主题,协程就是一种可以在代码的各种预定义位置暂停和恢复执行的函数,它避免了无意义的调度,由此提高代码性能。而子程序是一种特殊的协同程序,它只有单一入口,通过回调来完成执行。Python 的协程「现有的以生成器为基础的协程和新提出的协程」不是一般意义上的协程,因为在执行暂停时它们只能将控制权转给调用者,而不是像常见的那样将控制权转给别的协程。辅之以事件循环,协程可用于异步处理,尤其是在 I / O 中。

Python 当前支持的协程基于 PEP342 增强型生成器,于 Python 2.5 版本开始采用。该 PEP 将 yield 语句改为表达式,并为生成器增加了一些新的方法 「 send() , throw() , and close() 」 ,同时确保 close() 方法在生成器进入垃圾回收阶段时得到调用。该功能在 Python 3.3 版本的 PEP 380 中得到进一步增强,它通过增加 yield 表达式,允许生成器将部分功能授予另一个生成器「即子生成器」。

以上方法都使协程依赖于生成器,这使得在代码段何处进行异步调用变得令人困惑,且颇受限制。尤其,with 和 for 声明在理论上可以将协程用于异步调用,但 Python 语法在那些位置不允许使用 yield 表达式,因此无法进行异步调用。此外,如果协程的重构将 yield 或 yield from 从函数中移除 ,它就不再被视为协程,这会导致一些不明显的错误; asyncio 模块通过 @asyncio.coroutine 装饰器来弥补这方面的不足。

PEP 492 旨在解决以上所有问题。其想法源于 Yury Selivanov 在四月中旬提出的 python-ideas 邮件列表,该想法受到很多人热情追捧。在5月5日,Guido van Rossum 同意将它添加在 Python 3.5 版本中。不仅如此,5月12日就得到执行。一切都进展迅速,尽管最终该方法还是在 python-idea 和 python-dev 方面引起热情讨论。

从语法角度看,变化相当简单:

    async def read_data(db):
        data = await db.fetch('SELECT ...')
    ...

这个例子「来源于 PEP」将使用新的 async def 构造函数创建一个 read_data() 协程。 await 表达式将暂停执行 read_data() ,直到 db.fetch() await able 完成并返回其结果。await 类似于 yeild from ,但它会确保其参数 awaitable。

此外还有几种不同类型的 awaitable。一种是本地的协程对象,在调用本地协同程序后的返回为 awaitable,还有基于生成器且有 @types.coroutine 装饰的协程。还有一种是未来对象,它代表着在未来完成的操作,也是 awaitable。 __await __() 方法在 awaitable 的对象都会出现。

然而,向一种语言添加新的关键字时会出现这样的问题:任何与关键字名字相同的变量都会成为语法错误。为了避免该问题,Python 3 .5 和 3.6 版本将 “softly deprecate “ 「温柔弃用」 async 和 wait 为变量名,而不将他们当做语法错误。解析器会跟踪 async def 块,并将块内的关键字区别对待,从而使现有的使用继续有效。

新的特性中,异步还有两种新用途:异步内容管理器(with)和迭代器(for)。在协程里,这两种构造函数的示例如下:

	async def commit(session, data):
	...
	async with session.transaction():
		...
		await session.update(data)
		...
		...
		async for row in Cursor():
			print(row)

异步内容管理器必须实现两个异步方法, __aenter __()__aexit __() ,他们都返回 awaitables;异步迭代器须实现 __aiter __()__anext __() 。这些方法都是现有的同步内容管理器和迭代器的异步版本。

此前主要的讨论是延期执行的 “cofunction” 功能 PEP 3152 是否会是更好的起点,该 PEP 的作者 Greg Ewing 提出了此问题。但有很多人认为 Selivanov 提议的语法更适合 codef,cocall ,也有人更加赞同 Ewing 的提议。这样来来回回的争论了很多次。有一些人认为cofunction 的语法在处理某些情况时相当复杂并且不符合 Python 语言的特性。后来 Van Rossum 总结了 cofunctions 语法存在的问题,并拒绝采纳该方法。

此外,还有几点关于附加异步功能的建议值得讨论,但并不紧急。对于关键词的讨论有些本末倒置。 await 的优先级问题也讨论了一段时间,结果是,不同于 yeild 和 yeild from 仅有最低优先级,await 具有较高的优先级。

但 Mark Shannon 抱怨说,实现 Selivanov 的建议并不需要增加新的语法。其他人也提出了类似的意见,但 Selivanov 或其他支持者并未对此提出反驳。关键在于简化协同程序的编写。除此之外,Van Rossum 希望协同程序暂停的位置能够显而易见,查看代码就能发现:

新的语法才是 PEP 存在的意义。我希望通过句法结构就能判断出协程的悬停点。

在两三周后,发布了多个版本的 PEP ,引起了诸多辩论。Selivanov 耐心地解释他的想法,并根据反馈意见不断修正自己的想法。异步协程特性对 Python 语言的未来很可能至关重要,整个探索过程都很快,很顺遂。不过,Python 开发者们将这些想法付诸实践很可能还需要一段时间。

原文地址: Python coroutines with async and await

参考文章: 对Python中yield和协程的理解

本文系OneAPM 工程师翻译。OneAPM 是应用性能管理领域的新兴领军企业,能帮助企业用户和开发者轻松实现:缓慢的程序代码和 SQL 语句的实时抓取。想阅读更多技术文章,请访问 OneAPM官方博客。

本文链接:http://www.4byte.cn/learning/119786/yi-bu-deng-dai-de-python-xie-cheng.html