我最近一直在阅读约Stackless Python，与香草cPython相比，它似乎有很多优势。它具有像无限递归，微线程，延续等很酷的功能，同时比cPython更快（大约10％，如果the Python wiki可以相信）和兼容它（至少版本2.5,2.6和3.0）。Stackless Python的缺点是什么？
所有这些看起来都太好了，以至于没有。然而，TANSTAAFL，我看不到Python社区中Stackless的热情，而PEP 219从未实现过。这是为什么？ Stackless有什么缺点？ Stackless'衣柜里藏着什么骷髅？
（我知道无堆栈不提供真正的并发性，只是在并行方式编程更简单的方法，它并没有真正困扰我。）
我不知道Wiki上的“Stackless速度快10％”是从哪里来的，但是我再也没有试过测量这些性能数字。我无法想象Stackless如何做出重大改变。
Stackless是一个惊人的工具，带有几个组织/政治问题。
第一个来自历史。 Christian Tismer开始谈论10年前最终变成Stackless的事情。他了解他想要什么，但很难解释他在做什么，为什么人们应该使用它。这部分是因为他的背景没有关于协同程序这样的想法的CS培训，并且因为他的演示和讨论都是以实现为导向的，所以对于那些还没有深入了解的人来说，很难理解如何使用它作为解决方案他们的问题。
因此，最初的文档很差。有关于如何使用它的一些描述，以及来自第三方贡献者的最佳描述。根据PyCon的调查数据，在PyCon 2007上，我发表了一篇关于“Using Stackless”的演讲，该演讲非常好。 Richard Tew在收集这些内容方面做得非常好，更新了stackless.com，并在新的Python发行版出现时保持分发。他是EVE Online的开发者CCP Games的雇员，该开发者使用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支持者。 Tismer现在深深地参与了PyPy，这是Python的Python实现。他已经在PyPy中实现了Stackless功能，并认为它比Stackless本身优越得多，并且认为PyPy是未来的方式。 Tew保持Stackless，但他对宣传不感兴趣。我考虑过扮演这个角色，但看不到我能从中获得收入。
虽然如果你想在Stackless培训，请随时contact me！ :)
我也有兴趣在这里的答案。我用Stackless玩过了一下，看起来这对标准Python来说是一个很好的补充。
如果Python想要更改为不同的堆栈，PEP 219确实提到了从C代码调用Python代码的潜在困难。需要有方法来检测和防止这种情况（避免垃圾堆栈）。我认为这很容易理解，所以我也想知道为什么Stackless必须独立。
如果我没记错的话，Stackless将被列入官方CPython，但Stackless的作者告诉CPython人员不要这样做，因为他计划对代码库做一些重大更改 - 可以推测他希望稍后项目更成熟时进行整合。
来源？我觉得这很有趣，但我显然无法相信你，因为你这么说。如果你错了，我会看起来很傻，我开始讨论它有多有趣。 – 2009-02-26 04:18:35
优秀的点。对不起，我没有参考资料，因为它在freenode的#python中进行了irc对话，但是我确实设法在http://gnosis.cx/download/charming_python_10_outtakes.html上找到一个古老的邮件列表对话，它提供了很多对情况更有见识。 – Arafangion 2009-02-26 04:48:46
找到这个讨论花了相当长的时间。在那个 的时间，我不是在PyPy上，而是和psyco有了2年的恋情，直到健康完全停止了这一切。我现在再次活跃并设计了一种替代方法 - 将在EuroPython 2012上展示它。
安德鲁斯的大部分陈述都是正确的。一些 小增加：
Stackless比10年前的CPython快得多，因为我优化了解释器循环。当时，圭多还没有做好准备。几年后，人们做了类似的优化，甚至更多更好的，这使得Stackless有点慢，正如预期的那样。
关于包含：嗯，一开始我非常坚强，并且相信Stackless是一条路。后来，当它几乎可能被包括在内时，我对此失去了兴趣，并且宁愿让它保持这种状态，部分地出于挫折感，部分地对 保持对Stackless的控制。
像“其他实现不能这样做”的论点总是对我跛脚，因为还有其他例子可以使用这个参数。我想我最好忘了这一点，并与Guido保持友好的关系，并拥有自己的发行版。
同时事情正在改变。我工作的PyPy和无堆栈作为扩展将谈论有时后
干杯克里斯 -
PEP 219是9岁和严重过时。 “从C代码调用Python代码”的困难仅在PEP中讨论的实现中，并且不在Stackless中。 PEP（“Stackless Python”）的名称有点用词不当，它从Stackless中吸取了灵感，就是这样。 – 2009-02-26 13:00:02