因为工作中慢慢开始用python的协程,所以想更好的理解一下实现方式,故翻译此文
原文中把词汇表放到最后,但是我个人觉得放在最开始比较好,这样可以增加当你看原文时的理解程度
原生协程函数 Native coroutine function:
由async def定义的协程函数,可以使用await和return value语句
原生协程 Native coroutine:
原生协程函数返回的对象。见“await表达式”一节。
基于生成器的协程函数 Generator-based coroutine function:
基于生成器语法的协程,最常见的是用 @asyncio.coroutine装饰过的函数。
基于生成器的协程 Generator-based coroutine:
基于生成器的协程函数返回的对象。
协程 Coroutine:
“原生协程”和“基于生成器的协程”都是协程。
协程对象 Coroutine object:
“原生协程对象”和“基于生成器的协程对象”都是协程对象。
Future-like对象 Future-like object:
一个有__await__方法的对象,或一个有tp_as_async->am_await函数的C语言对象,它们返回一个迭代器。Future-like对象可以在协程里被一条await语句消费(consume)。协程会被await语句挂起,直到await语句右边的Future-like对象的__await__执行完毕、返回结果。见“await表达式”一节。
Awaitable
一个Future-like对象或一个协程对象。见“await表达式”一节。
异步上下文管理器 Asynchronous context manager:
有__aenter__和__aexit__方法的对象,可以被async with语句使用。见“异步上下文管理器和‘async with’”一节。
可异步迭代对象 Asynchronous iterable:
有__aiter__方法的对象, 该方法返回一个异步迭代器对象。可以被async for语句使用。见“异步迭代器和‘async for’”一节。
异步迭代器 Asynchronous iterator:
有__anext__方法的对象。见“异步迭代器和‘async for’”一节。
随着互联网和连接程序的增长,引发了对响应性和可扩展代码的需求,该提议的目标是让我们共容易的通过编写显示异步,高并发的python代码并且更加Pythonic
它提出把写成的概念独立出来,并引入新的支持语法。最终的目标是帮助在python中建立一个通用的,易于接近的异步编程构思模型,并使其尽可能接近于同步编程(说白了就是让你通过类似写同步编程的方式,写出异步代码)
这个PEPE建设异步任务是类似于标准模块asyncio.events.AbstractEventLoop的事件循环调度和协调。虽然这个PEP不依赖人去特定的时间循环实现,但它仅仅与使用yield作为调度程序信号的协程类型相关,表示协程将等待知道事件(例如:IO)完成
我们相信,这里提出的更改将有助于python在快速增长的异步编程领域保持更好的竞争力,因为许多其他语言已经采或将要采用类似的功能
对Python 3.5的初始beta版本的反馈导致重新设计支持此PEP的对象模型,以更清楚地将原生协程与生成器分离 - 而不是一种新的生成器,现在原生协程有明确的独立类型
这个改变主要是为了解决原生协程在tornado里使用出现的一些问题
在CPython3.5.2 中更新了__aiter__ 协议。
在3.5.2之前,__aiter__ 是被期望返回一个等待解析为异步迭代器,从3.5.2开始,__aiter__ 应该直接返回异步迭代器
如果在3.5.2中使用旧协议中,Python将引发PendingDeprecationWarning异常
在CPython 3.6中,旧的__aiter__协议仍将受到引发DeprecationWarning的支持
在CPython 3.7中,将不再支持旧的__aiter__协议:如果__aiter__返回除异步迭代器之外的任何内容,则将引发RuntimeError。
当前的Python支持通过生成器(PEP342)实现协程,并通过PEP380中引入的yield from 语法进一步增强,这种方法有很多缺点:
这个PEP把协程从生成器独立出来,成为Python的一个原生事物。这会消除协程和生成器之间的混淆,方便编写不依赖特定库的协程代码。也为linter和IDE进行代码静态分析提供了机会。
使用原生协程和相应的新语法,我们可以在异步编程时使用上下文管理器(context manager)和迭代器。如下文所示,新的async with语句可以在进入、离开运行上下文(runtime context)时进行异步调用,而async for语句可以在迭代时进行异步调用。
该提议引入了新的语法和语义来增强Python对协程支持。
请理解Python现有的协程(见PEP 342和PEP 380),这次改变的动机来自于asyncio框架(PEP 3156)和Confunctions提案(PEP 3152,此PEP已经被废弃)。
由此,在本文中,我们使用“原生协程”指用新语法声明的协程。“生成器实现的协程”指用传统方法实现的协程。“协程”则用在两个都可以使用的地方。
使用以下语法声明原生协程:
async def read_data(db):
pass
协程语法的关键点:
types模块添加了一个新函数coroutine(fn),使用它,“生成器实现的协程”和“原生协程”之间可以进行互操作。
@types.coroutine
def process_data(db):
data = yield from read_data(db)
...
该函数将CO_ITERABLE_COROUTINE标志应用于生成器函数的代码对象,使其返回一个协程对象。如果fn不是生成器函数,它将被包装。如果它返回一个生成器,它将被包装在一个等待的代理对象中(参见下面的等待对象的定义)。
types.coroutine()不会设置CO_COROUTINE标识,只有用新语法定义的原生协程才会有这个标识。
新的await表达式用于获得协程执行的结果:
async def read_data(db):
data = await db.fetch('SELECT ...')
...
await 和yield from 是非常类似的,会挂起read_data的执行,直到等待db.fetch完成并返回结果数据。
await使用yield from的实现,但是加入了一个额外步骤——验证它的参数类型。await只接受awaitable对象,awaitable对象是以下的其中一个:
在本文中,有__await__方法的对象被称为Future-like对象(协程会被await语句挂起,直到await语句右边的Future-like对象的__await__执行完毕、返回结果。)
如果__await__返回的不是一个迭代器,则引发TypeError异常。
在CPython C API,有tp_as_async.am_await函数的对象,该函数返回一个迭代器(类似__await__方法)
如果在async def函数之外使用await语句,会引发SyntaxError异常。这和在def函数之外使用yield语句一样。
如果await右边不是一个awaitable对象,会引发TypeError异常。
有效的语法示例
Expression | Will be parsed as |
---|---|
if await fut: pass | if (await fut): pass |
if await fut + 1: pass | if (await fut) + 1: pass |
pair = await fut, 'spam' | pair = (await fut), 'spam' |
with await fut, open(): pass | with (await fut), open(): pass |
await foo()['spam'].baz()() | await ( foo()['spam'].baz()() ) |
return await coro() | return ( await coro() ) |
res = await coro() ** 2 | res = (await coro()) ** 2 |
func(a1=await coro(), a2=0) | func(a1=(await coro()), a2=0) |
await foo() + await bar() | (await foo()) + (await bar()) |
-await foo() | -(await foo()) |
无效的用法
Expression | Should be written as |
---|---|
await await coro() | await (await coro()) |
await -coro() | await (-coro()) |
异步上下文管理器(asynchronous context manager),可以在它的enter和exit方法里挂起、调用异步代码。
为此,我们设计了一套方案,添加了两个新的魔术方法:__aenter__和__aexit__,它们必须返回一个awaitable。
异步上下文管理器的一个示例:
class AsyncContextManager:
async def __aenter__(self):
await log('entering context')
async def __aexit__(self, exc_type, exc, tb):
await log('exiting context')
采纳了一个异步上下文管理器的新语法
async with EXPR as VAR:
BLOCK
这在语义上等同于:
mgr = (EXPR)
aexit = type(mgr).__aexit__
aenter = type(mgr).__aenter__(mgr)
VAR = await aenter
try:
BLOCK
except:
if not await aexit(mgr, *sys.exc_info()):
raise
else:
await aexit(mgr, None, None, None)
与常规with语句一样,可以在单个async with语句中指定多个上下文管理器。
在使用async with时,如果上下文管理器没有__aenter__和__aexit__方法,则会引发错误。在async def函数之外使用async with则会引发SyntaxError异常。
使用异步上下文管理器,可以轻松地为协同程序实现适当的数据库事务管理器:
async def commit(session, data):
...
async with session.transaction():
...
await session.update(data)
...
加锁的处理也更加简洁
async with lock:
...
而不再是:
with (yield from lock):
...
异步迭代器可以在它的iter实现里挂起、调用异步代码,也可以在它的__next__方法里挂起、调用异步代码。要支持异步迭代,需要:
一个一步迭代的例子:
class AsyncIterable:
def __aiter__(self):
return self
async def __anext__(self):
data = await self.fetch_data()
if data:
return data
else:
raise StopAsyncIteration
async def fetch_data(self):
...
采纳了一个迭代异步迭代器的新语法:
async for TARGET in ITER:
BLOCK
else:
BLOCK2
在语义上等同于:
iter = (ITER)
iter = type(iter).__aiter__(iter)
running = True
while running:
try:
TARGET = await type(iter).__anext__(iter)
except StopAsyncIteration:
running = False
else:
BLOCK
else:
BLOCK2
如果async for的迭代器不支持__aiter__方法,则引发TypeError异常。如果在async def函数外使用async for,则引发SyntaxError异常。
和普通的for语句一样,async for有一个可选的else分句。
使用异步迭代协议,可以在迭代期间异步缓冲数据:
async for data in cursor:
...
其中cursor是一个异步迭代器,它在每N次迭代后从数据库中预取N行数据。
以下代码说明了新的异步迭代协议:
class Cursor:
def __init__(self):
self.buffer = collections.deque()
async def _prefetch(self):
...
def __aiter__(self):
return self
async def __anext__(self):
if not self.buffer:
self.buffer = await self._prefetch()
if not self.buffer:
raise StopAsyncIteration
return self.buffer.popleft()
然后,可以这样使用Cursor类
async for row in Cursor():
print(row)
与下述代码相同:
i = await Cursor().__aiter__()
while True:
try:
row = await i.__anext__()
except StopAsyncIteration:
break
else:
print(row)
以下是将常规迭代转换为异步迭代的实用程序类。虽然这不是一件非常有用的事情,但代码说明了常规迭代器和异步迭代器之间的关系。
class AsyncIteratorWrapper:
def __init__(self, obj):
self._it = iter(obj)
def __aiter__(self):
return self
async def __anext__(self):
try:
value = next(self._it)
except StopIteration:
raise StopAsyncIteration
return value
async for letter in AsyncIteratorWrapper("abc"):
print(letter)
协程在内部仍然是基于生成器实现的,因此,在PEP479之前,下面两者是没有区别的
def g1():
yield from fut
return 'spam'
和
def g2():
yield from fut
raise StopIteration('spam')
由于PEP 479已被正式采纳,并作用于协程,以下代码的StopIteration会被包装(wrapp)成一个RuntimeError。
async def a1():
await fut
raise StopIteration('spam')
所以,要想通知外部代码迭代已经结束,抛出一个StopIteration异常的方法不行了。因此,添加了一个新的内置异常StopAsyncIteration,用于表示迭代结束。
此外,根据PEP 479,协程抛出的所有StopIteration异常都会被包装成RuntimeError异常。
本节仅适用于具有CO_COROUTINE的原生协程,即使用新的async def 定义的函数
对于asyncio模块里现有的“基于生成器的协程”,仍然保持不变。
为了把协程和生成器的概念区分开来:
协程是基于生成器实现的,因此它们有共同的代码。像生成器对象那样,协程也有throw(),send()和close()方法。 对于协程,StopIteration和GeneratorExit起着同样的作用(虽然PEP 479已经应用于协程)。详见PEP 342、PEP 380,以及Python文档。
对于协程,send(),throw()方法用于往Future-like对象发送内容、抛出异常。
初级开发者在使用协程时可能忘记使用yield from语句,比如:
@asyncio.coroutine
def useful():
asyncio.sleep(1) # this will do nothing without 'yield from'
为了调试这种错误,在asyncio中有一个特殊的调试模式,其中@coroutine装饰器用一个特殊对象包装所有函数,并使用析构函数记录警告。每当一个包装的生成器被垃圾回收时,就会生成一条详细的日志消息,其中包含有关定义装饰器函数的确切位置,堆栈跟踪收集位置等的信息.Wrapper对象还提供了一个方便的__repr__函数,其中包含有关生成器的详细信息。
为了更好地与现有框架(如Tornado,见[13])和编译器(如Cython,见[16])集成,增加了两个新的抽象基类(ABC):
注意,“基于生成器的协程”(有CO_ITERABLE_COROUTINE标识)并不实现__await__方法,因此它们不是collections.abc.Coroutine和collections.abc.Awaitable的实例:
@types.coroutine
def gencoro():
yield
assert not isinstance(gencoro(), collections.abc.Coroutine)
# however:
assert inspect.isawaitable(gencoro())
为了便于测试对象是否支持异步迭代,还添加了两个ABC: