Stackless Python 是什么--做者采访

     一直没明白Stackless Python什么意思，看到这一段3年前对做者的采访译文(原文找不到)，稍微有点理解了。但如今Stackless Python感受没怎么更新了。

Stackless Python：采访创始人 Christian Tismer

第一次见到 Stackless Python 时，它象是 CPython 的一个小支流。谈到编码，Stackless 对实际的 Python C 代码只作了小小更改（并从新定义“事实”）。不过，Christian Tismer（ Stackless Python 的创始人）在 Stackless 中引入的概念很是深奥。它是“延续性”的概念（而且以 Python 对他们编程的方法）。

要尝试用最简单的术语解释它，延续性就是一种表示法，在程序中的特定点上，程序的每样事物均可以连续执行。延续性是依赖于初始条件的潜在。不是以传统方式进行循环，它可能使用不一样的初始条件递归调用相同的持续性。我看到过的一种归纳说法是，从理论上说，延续性更基本并位于 每一个其它控制结构下。若是这些想法把您搞糊涂了，没必要担忧；这是正常的反应。

阅读 参考资料中 Tismer 的背景文章是进一步理解的良好开端。最好在阅读该文章后继续阅读他的参考资料。但对目前来讲，让咱们在更通常的级别上与 Tismer 进行交谈：

Mertz：Stackless Python 确切来讲是什么？有什么初学者能够理解的概念可以解释有关 Stackless 的不一样之处？

Tismer：Stackless Python 是一种不在 C 堆栈上保存状态的 Python 实现。它的确有堆栈 -- 要多少有多少 -- 但这些是 Python 堆栈。

C 堆栈不能从例如 C 这样的语言以干净的方式进行修改，除非以预期的顺序进行。它对您施加了很大限制：您必须回到这里，与您离开的方向正好相反。

“普通的”程序员一开始不会认为这是个限制。他们必须从开始就要学会将想法转向堆栈。堆栈没有什么坏处，而且一般它们施加的执行顺序就是实际上的顺序，但这并不意味着咱们必须等待一个这样的堆栈序列完成才能运行另外一序列。

程序员在必须执行非阻塞调用和回调时意识到这一点。堆栈忽然挡住去路，咱们必须使用线程，或将状态明确存储在对象中，或者构建显式的可切换堆栈等等。Stackless 的目的是帮助程序员避免这些问题。

Mertz：Stackless 的目标是达到与 CPython 100% 二进制兼容。是吗？

Tismer：Stackless 此刻就是 100% 的二进制兼容。这意味着：安装了 Python 1.5.2 后，用个人 Python15.dll 替换，每一个文件仍能工做，包括每一个扩展模块。这不是目标，而是要求，由于我不但愿关注全部扩展。

Mertz：我认为 Stackless Python 绝对能吸引人们对它加以了解。和大多数讲实际的程序员同样，我在彻底理解它时遇到了难题，但这是使它显得特别有趣的一部分。

Tismer：是啊，我也很讲实际，您能够想象在没有任何持续性概念，而且不知道在 Python 中它究竟是什么样的状况下实现这样一件东西有多困难。没法想象某些事物，但要投入去作是我最大的挑战。完成后就很容易想象，也很容易从新设计。但在六个月的全职工做中，我猜有五个月的时间是在凝视屏幕和敲打键盘。

延续性很难销售。协同程序和生成器，特别是微线程还稍容易一点。全部以上产品都  能够在没有显式持续性的状况下实现。但有了持续性后，会发现转向其它结构所花费的步骤很是少，持续性就是使用的方法。因此我要改变个人营销策略，再也不尝试销售持续性，而是它们的成果。对于可以看到光明的人来讲，持续性仍然存在。

Mertz：有一个关于美国工程师和法国工程师的笑话。美国小组给法国小组带来一个原型。法国小组的反应是：“它在实践中工做得不错；但在理论上靠得住吗？”我想这个笑话多是要嘲弄一下“法国人”的做风，但在我本身看来，我彻底认同“法国人”的反应。排除笑话中任何针对特定民族的刻板模式，对它的认同是吸引我去了解 Stackless 的缘由。CPython 在实践中使用，而 Stackless 在理论中使用！（换句话说，对于我我的，持续性的抽象纯粹性比微线程的上下文切换加速更有趣）。

Tismer：我也有相似的感受。认识到 CPython 能够在不涉及 C 堆栈的状况下实现后，我确信它  必须用这种方式实现；其它全部方法都很荒唐。CPython 已经为框架对象付出了代价，但它使用 C 堆栈尝试它们更是丧失了全部自由。我以为我必须解放 Python。:-)

我 1999 年 5 月开始这个项目。Sam Rushing 曾对硬件协同程序的实现有过粗略的研究，因此一场有关 Python 设备的讨论开始了。将堆栈复制作大量更改永远也不能将它变成 Python，这一点当时就很清楚。但可移植的、干净实现的协同程序可能能够。不幸的是，这是不可能的。五年前，Steve Majewski 在乎识到若是不彻底重写 Python 就没法解决这个问题以后就放弃了。

那就是挑战所在。我必须查明它。它若是是可能的，我就实现它；若是不可能，我就要证实这种不可能性。不久之后，通过了首次考虑和尝试后，Sam 告诉我有关 call/cc 以及它是如何强大。那时，我对它们在哪些方面比协同程序更强大一点概念也没有，但我相信他并实现了它们；六七次之后，总要彻底重写，使我有了更深刻的理解。

我但愿最终可以以使人眼花缭乱的高速度建立线程，但个人初衷是发现究竟我能到达什么地步。

Mertz：在实践方面，Stackless 可能有哪些性能改进呢？这些改进在当前的实现中有多重要？它还有多少潜力可挖？哪些特定类型的应用程序最有可能从 Stackless 中受益？

Tismer：在当前的实现中，Stackless 比传统调用方案来讲并不占太大的优点。普通的 Python 对新解释器开始递归。Stackless 展开到一个调度器，而后从那里启动解释器。这点几乎同样。实际的改进在于协同程序和线程的实现。它们须要由类模拟，或者须要是标准 Python 中的实际线程，但使用 Stackless，它们能够更直接地实现。

若是不对操做码集作巨大的更改，核心的更多改进就显得不太可能。但一个具备对其它地方延续性更多内置支持的再实现能够大大提升速度。

受益最大的那些特定应用程序多是 Swarm 仿真，或有许多角色扮演极小任务的多人游戏。一例就是正在使用 Stackless Python 开发的 EVE 游戏（请参阅下面的  参考资料）。

Mertz：对于将 Stackless 合并到 CPython 主流您以为如何？Stackless 是做为一个分支好呢，仍是成为核心版本的话有些方面会更好？

Tismer：有一些支持和反对的争论。反对：只要我不放弃 Stackless 实现，它就是个人，我不须要讨论如何以及为何的问题。但同时，我在尽力（但未能）追赶 CVS。最好让其它人来作。

其它没必要对稀奇古怪的事物感兴趣的那些 Python 用户根本不会认识 Stackless；只是事实上它碰巧更快，最大递归级别如今是一个选项而不是硬件限制。对每一个用户还有另外一个保证：将有可腌制 (pickleable) 执行状态。这意味着能够在程序运行的时侯保存它，将它发送给朋友，而后继续运行。

最后，假使个人全部东西都变成核心，我就彻底同意；但我不但愿看到一个就好象建议过屡次的不完整的解决方案。

Mertz：对 Stackless 的将来方向有什么想法吗？将生产什么新的不一样产品？Stackless 仍然受一些递归的困扰。它们会消失吗？

Tismer：将部分地实现腌制支持。首先对于微线程使用，由于如今它们提供最干净的概念。它们在“洁净室”里生活，这里不存在余下的递归问题。个人最终目标是从 Python 中除去  所有解释器递归。Stackless 的某些部分仍旧有递Stackless Python：采访创始人 Christian Tismer定义的 __xxx__ 方法。要定案很难，由于咱们须要更改不少东西、添加新的操做码、展开某些内部调用序列等等。