我最近一直在阅读有关Stackless Python的内容，与普通 cPython 相比，它似乎有很多优势。它具有无限递归、微线程、延续等所有很酷的特性，同时比 cPython 快（大约 10%，如果相信Python wiki的话）并且与它兼容（至少版本2.5、2.6和 3.0)。
所有这些看起来都好得令人难以置信。然而，在 TANSTAAFL中，我没有看到 Python 社区对 Stackless 有太多热情，而且PEP 219从未实现过。这是为什么？Stackless 的缺点是什么？Stackless 的衣橱里藏着什么骷髅？
（我知道 Stackless 不提供真正的并发，只是一种更简单的并发编程方式。它并没有真正困扰我。）
我不知道 Wiki 上的“Stackless 快 10%”是从哪里来的，但话说回来，我从未尝试过衡量这些性能数字。我想不出 Stackless 做了什么来产生如此大的影响。
Stackless 是一个了不起的工具，它有几个组织/政治问题。
第一个来自历史。大约 10 年前，Christian Tismer 开始谈论最终成为 Stackless 的东西。他知道自己想要什么，但很难解释他在做什么以及为什么人们应该使用它。这部分是因为他的背景没有接受过关于协程等想法的 CS 培训，并且因为他的演示和讨论非常面向实现，这对于没有深入了解后续的人来说很难理解如何使用它作为解决方案他们的问题。
因此，最初的文档很差。有一些关于如何使用它的描述，其中最好的来自第三方贡献者。根据 PyCon 的调查数据，在 PyCon 2007 上，我发表了关于“使用 Stackless ”的演讲，结果非常好。Richard Tew 在收集这些、更新stackless.com以及在新的 Python 版本出现时维护分发方面做得很好。他是CCP Games的员工，EVE Online 的开发人员，该公司使用 Stackless 作为其游戏系统的重要组成部分。
CCP 游戏也是人们谈论 Stackless 时使用的最大的现实示例。Stackless 的主要教程是 Grant Olson 的《Introduction to Concurrent Programming with Stackless Python》，也是面向游戏的。我认为这给人们一种歪曲的想法，即 Stackless 是面向游戏的，而游戏更容易面向延续。
另一个困难是源代码。在最初的形式中，它需要对 Python 的许多部分进行更改，这让 Python 负责人 Guido van Rossum 保持警惕。我认为部分原因是对 call/cc 的支持后来被删除，因为“当有更好的高级表单时，它太像支持 goto”。我不确定这段历史，所以把这一段读作“Stackless 过去需要太多改变”。
后来的版本不需要更改，Tismer 继续推动将其包含在 Python 中。虽然有一些考虑，但官方立场（据我所知）是 CPython 不仅是 Python 实现，而且它是作为参考实现，它不包含 Stackless 功能，因为它不能由 Jython 实现或铁蟒。
绝对没有“对代码库进行重大更改”的计划。来自 Arafangion 的引用和参考超链接（见评论）大约来自 2000/2001。结构上的变化早就做了，就是我上面说的。现在的 Stackless 是稳定和成熟的，在过去几年中只对代码库进行了细微的调整。
Stackless 的最后一个限制 - Stackless 没有强烈的拥护者。Tismer 现在深入参与了PyPy，它是 Python 的 Python 实现。他在 PyPy 中实现了 Stackless 功能，认为它比 Stackless 本身优越得多，并认为 PyPy 是未来的方向。Tew 维护着 Stackless，但他对宣传不感兴趣。我考虑过担任那个角色，但不知道如何从中获得收入。
如果您想在 Stackless 中进行培训，请随时与我联系！:)
找到这个讨论花了很长时间。那时我不在 PyPy 上，但与 psyco 有 2 年的恋情，直到健康突然停止了这一切。我现在再次活跃并设计一种替代方法 - 将在 EuroPython 2012 上展示它。
大多数安德鲁斯的陈述是正确的。一些小的补充：
10 年前，Stackless 比 CPython 快得多，因为我优化了解释器循环。那时，圭多还没有为此做好准备。几年后，人们做了类似的优化，甚至更多更好的优化，这使得 Stackless 有点慢，正如预期的那样。
关于包容性：嗯，一开始我非常咄咄逼人，并坚信 Stackless 是要走的路。后来，当几乎有可能被纳入时，我对此失去了兴趣，宁愿让它保持这种状态，部分是出于沮丧，部分是为了保持对 Stackless 的控制。
像“其他实现无法做到”这样的论点对我来说总是很蹩脚，因为还有其他例子也可以使用这个论点。我想我最好忘记这一点，并与 Guido 保持良好的友谊，拥有自己的发行版。
与此同时，情况再次发生变化。我正在开发 PyPy 和 Stackless 作为扩展 有时稍后会谈到
干杯——克里斯
如果我没记错的话，Stackless 计划包含在官方 CPython 中，但是 stackless 的作者告诉 CPython 的人不要这样做，因为他计划对代码库进行一些重大更改——大概他希望稍后完成集成该项目更加成熟。
我也对这里的答案感兴趣。我用 Stackless 玩了一点，看起来它会是标准 Python 的一个很好的可靠补充。
如果 Python 想要更改为不同的堆栈，PEP 219 确实提到了从 C 代码调用 Python 代码的潜在困难。需要有方法来检测和防止这种情况（以避免破坏 C 堆栈）。我认为这很容易处理，所以我也想知道为什么 Stackless 必须独立存在。