似乎有两种基于生成器的协程:
- 来自a reply,Jim Fasarakis Hilliard:
基于生成器的协同程序:由types.coroutine包装的生成器(def yield) . 如果需要将它包含在coroutine对象中,则需要将其包装在types.coroutine中 .
- 来自Nutshell中的Python,它没有明确地将其称为“基于生成器的协同程序”:
当您编写基于asyncio的Python代码(理想情况下也使用asyncio.org的附加模块)时,您通常会编写协同程序函数 . 包括Python 3.4,这些函数是使用第95页的“yield from(v3-only)”中描述的yield语句的生成器,使用@ asyncio.coroutine修饰,在第518页的“asyncio coroutines”中介绍;
来自https://www.python.org/dev/peps/pep-0492/#differences-from-generators
基于生成器的协程(用于asyncio代码必须用@ asyncio.coroutine修饰)
http://masnun.com/2015/11/13/python-generators-coroutines-native-coroutines-and-async-await.html也称之为"generator-based coroutine" .
这两种基于发生器的协同程序是否具有相同的概念?
如果没有,他们在目的和用途上的差异是什么?
谢谢 .
2 回答
他们是同一种协程 .
types.coroutine
和asyncio.coroutine
只是创建它们的两种不同方式 .asyncio.coroutine
比较早,在引入async
协同程序之前,其功能已经从原来的行为发生了一些变化,现在存在async
协同程序 .asyncio.coroutine
和types.coroutine
具有微妙的不同行为,特别是如果应用于除生成器函数之外的任何其他内容,或者如果asyncio位于debug mode中 .就我而言,
async def
是定义协程的 proper 方式 .yield
和yield from
在发电机中有它们的用途,它们也用于实现“期货”,它是处理不同协程上下文之间切换的低级机制 .几个月前我做了this diagram总结了他们之间的关系 . 但坦率地说,你可以放心地忽略整个业务 . 事件循环可以处理管理协程执行的所有低级细节,因此请使用其中一个,如asyncio . 其他事件循环也有
asyncio
兼容的包装器,比如我自己的glibcoro用于GLib / GTK .换句话说,坚持
asyncio
API,你可以编写“event-loop-agnostic”协同程序!