异步等待的 Python 协程

异步等待的 Python 协程

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

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

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

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

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

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

从语法角度看，变化相当简单：

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

此外还有几种不同类型的 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 __()。这些方法都是现有的同步内容管理器和迭代器的异步版本。

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

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

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

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