可爱的 Python: 用基于生成器的状态机和协同程序增加效率

核心提示： 幸运的是，用 Python 生成器模仿配备齐全的的协同程序相当容易，可爱的 Python: 用基于生成器的状态机和协同程序增加效率(7)，简单的窍门就是和上面样本代码中生成器十分类似的 scheduler() 函数，事实上，我所描述的框架的可用性作了回答：“和您想要的一样！&r

幸运的是，用 Python 生成器模仿配备齐全的的协同程序相当容易。简单的窍门就是和上面样本代码中生成器十分类似的 scheduler() 函数。事实上，我们所提出的状态机本身就是一个常见得多的协同程序框架模式。适应这种模式能克服 Python 生成器中仍存在的小缺陷（让粗心大意的程序员也能发挥出通心粉代码的全部力量）。

操作中的 Stategen

要想准确了解 stategen_test.py 中发生了什么，最简单的办法就是运行它：

清单 3. 运行 STATEGEN（手工跳转控制）

% python stategen_test.py
ONES State:　　　 @ 1.0
TWENTIES State:　 *26.1　 *25.3
ONES State:　　　 @ 4.2
TWENTIES State:　 *26.4　 *29.5　 *28.8
TENS State:　　　 #15.2　 #16.3　 #16.0
ONES State:　　　 @ 9.5　 @ 3.8
TENS State:　　　 #18.2　 #17.9
TWENTIES State:　 *24.4
TENS State:　　　 #19.6
TWENTIES State:　 *21.4
TENS State:　　　 #16.1　 #12.3
ONES State:　　　 @ 9.2　 @ 6.5　 @ 5.7
TENS State:　　　 #16.7
TWENTIES State:　 *26.4　 *30.0
[co-routine for jump?] twenties
...Jumping into middle of TWENTIES
TWENTIES State:
TENS State:　　　 #19.9
TWENTIES State:　 *26.4　 *29.4　 *27.5　 *22.7
TENS State:　　　 #19.9
TWENTIES State:　 *26.2　 *26.8
Exiting from exit()...

这个输出和前面的 statemachine_test.py 中的输出基本上是完全相同的。结果中的每一行分别表示在特定的处理程序或生成器中使用的流；在行的开头声明了流上下文。但是，每当另一个协同程序分支转到生成器内时，生成器版本 恢复执行（在一个循环内），而不仅仅是再次 调用处理程序函数。假设所有的 get_*() 协同程序体都包含在无限循环中，这点差异就不那么明显了。

要了解 stategen_test.py 中的本质差异，看看 exit() 生成器中发生了什么。第一次调用生成器-迭代器时，从用户处收集一个跳转目标（这是现实中的应用中有可能利用的事件驱动分支决策的一种简单情况）。然而，当再次调用 exit() 时，它位于生成器的一个稍后的流上下文中 ― 显示退出消息，并调用 sys.exit() 。交互作用样本中的用户完全可以直接跳转到“out_of_range”，不用转到另一个“处理程序”就退出（但是它 将执行一个到这个相同生成器内的递归跳转）。

结束语

我在介绍中说过，我期望状态机版本的协同程序运行速度大大超过前面介绍的带回调处理程序的类（class-with-callback-handler）"版本的速度。恢复生成器-迭代器效率要高得多。特定的示例如此简单，几乎不足以作为评判标准，但是我欢迎读者对具体结果进行反馈。

但不管我介绍的“协同程序模式”在速度方面可能取得什么样的进展，在它实现的惊人的通用流控制面前都会黯然失色。comp.lang.python 新闻组上的许多读者都曾询问过 Python 的新生成器有多通用。我想，我所描述的框架的可用性作了回答：“和您想要的一样！”对于大多数和 Python 有关的事情，对某些事情 编程通常比 理解它们要简单得多。试试我的模式；我想您会发现它很有用。