我最近一直在阅读有关 Stackless Python 的文章，与普通的 cPython 相比，它似乎有很多优点。 它具有所有这些很酷的功能，例如无限递归、微线程、延续等，同时比 cPython 更快（大约 10%，如果 Python wiki 是可信的）并且与其兼容（至少版本 2.5、2.6 和 3.0）。
所有这些看起来好得令人难以置信。 然而，TANSTAAFL，我没有看到 Python 社区对 Stackless 有太多热情，并且PEP 219 从未实现。 这是为什么？ Stackless 的缺点是什么？ Stackless的衣柜里藏着什么骷髅？
（我知道 Stackless 并不提供真正的并发，只是一种更简单的并发编程方式。它并没有真正困扰我。）
I've been reading recently about Stackless Python and it seems to have many advantages compared with vanilla cPython. It has all those cool features like infinite recursion, microthreads, continuations, etc. and at the same time is faster than cPython (around 10%, if the Python wiki is to be believed) and compatible with it (at least versions 2.5, 2.6 and 3.0).
All these looks almost too good to be true. However, TANSTAAFL, I don't see much enthusiasm for Stackless among the Python community, and PEP 219 has never come into realization. Why is that? What are the drawbacks of Stackless? What skeletons are hidden in Stackless' closet?
(I know Stackless doesn't offer real concurrency, just an easier way of programming in the concurrent way. It doesn't really bother me.)
发布评论
评论（4）
我不知道 Wiki 上“Stackless 快了 10%”的说法从何而来，但话又说回来，我从未尝试过衡量这些性能数字。 我想不出 Stackless 做了什么能产生这么大的影响。
Stackless 是一个令人惊叹的工具，但存在一些组织/政治问题。
第一个来自历史。 Christian Tismer 大约 10 年前开始谈论最终成为 Stackless 的事情。 他知道自己想要什么，但很难解释自己在做什么以及为什么人们应该使用它。 部分原因是他的背景没有接受过关于协程等想法的 CS 培训，而且他的演示和讨论非常面向实现，这对于那些尚未深入了解如何使用它作为解决方案的人来说很难理解。他们的问题。
因此，最初的文档很差。 有一些关于如何使用它的描述，其中最好的来自第三方贡献者。 在 PyCon 2007 上，我做了一个关于“使用 Stackless” 的演讲，根据PyCon 调查数字。 Richard Tew 在收集这些内容、更新 stackless.com 以及在新的 Python 版本出现时维护发行版方面做得非常出色。 他是 CCP Games 的员工，CCP Games 是 EVE Online 的开发商，该公司使用 Stackless 作为其游戏系统的重要组成部分。
CCP 游戏也是人们谈论 Stackless 时使用的最大的现实例子。 Stackless 的主要教程是 Grant Olson 的“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 for Python 的实现。 他在 PyPy 中实现了 Stackless 功能，并认为它比 Stackless 本身优越得多，并认为 PyPy 是未来的发展方向。 Tew 维护着 Stackless，但他对宣传不感兴趣。 我考虑过担任这个角色，但不知道如何从中赚取收入。
不过，如果您想接受 Stackless 培训，请随时联系我！ :)
I don't know where that "Stackless is 10% faster" on the Wiki came from, but then again I've never tried to measure those performance numbers. I can't think of what Stackless does to make a difference that big.
Stackless is an amazing tool with several organizational/political problems.
The first comes from history. Christian Tismer started talking about what eventually became Stackless about 10 years ago. He had an idea of what he wanted, but had a hard time explaining what he was doing and why people should use it. This is partially because his background didn't have the CS training regarding ideas like coroutines and because his presentations and discussion are very implementation oriented, which is hard for anyone not already hip-deep in continuations to understand how to use it as a solution to their problems.
For that reason, the initial documentation was poor. There were some descriptions of how to use it, with the best from third-party contributors. At PyCon 2007 I gave a talk on "Using Stackless" which went over quite well, according to the PyCon survey numbers. Richard Tew has done a great job collecting these, updating stackless.com, and maintaining the distribution when new Python releases comes up. He's an employee of CCP Games, developers of EVE Online, which uses Stackless as an essential part of their gaming system.
CCP games is also the biggest real-world example people use when they talk about Stackless. The main tutorial for Stackless is Grant Olson's "Introduction to Concurrent Programming with Stackless Python", which is also game oriented. I think this gives people a skewed idea that Stackless is games-oriented, when it's more that games are more easily continuation oriented.
Another difficulty has been the source code. In its original form it required changes to many parts of Python, which made Guido van Rossum, the Python lead, wary. Part of the reason, I think, was support for call/cc that was later removed as being "too much like supporting a goto when there are better higher-level forms." I'm not certain about this history, so just read this paragraph as "Stackless used to require too many changes."
Later releases didn't require the changes, and Tismer continued to push for its inclusion in Python. While there was some consideration, the official stance (as far as I know) is that CPython is not only a Python implementation but it's meant as a reference implementation, and it won't include Stackless functionality because it can't be implemented by Jython or Iron Python.
There are absolutely no plans for "significant changes to the code base". That quote and reference hyperlink from Arafangion's (see the comment) are from roughly 2000/2001. The structural changes have long been done, and it's what I mentioned above. Stackless as it is now is stable and mature, with only minor tweaks to the code base over the last several years.
One final limitation with Stackless - there is no strong advocate for Stackless. Tismer is now deeply involved with PyPy, which is an implementation of Python for Python. He has implemented the Stackless functionality in PyPy and considers it much superior to Stackless itself, and feels that PyPy is the way of the future. Tew maintains Stackless but he isn't interested in advocacy. I considered being in that role, but couldn't see how I could make an income from it.
Though if you want training in Stackless, feel free to contact me! :)
花了很长时间才找到这个讨论。 那时
当时我没有使用 PyPy，但与 psyco 有过两年的恋情，直到健康状况突然阻止了这一切。 我现在又开始活跃起来并设计一个
替代方法 - 将在 EuroPython 2012 上展示它。
大多数 Andrews 声明都是正确的。 一些
小幅补充：
Stackless 比 10 年前的 CPython 快得多，因为我优化了解释器循环。 当时，圭多还没有准备好。 几年后，人们做了类似的优化，甚至更多更好的优化，这使得 Stackless 慢了一点，正如预期的那样。
关于包容性：嗯，一开始我非常有进取心，并坚信 Stackless 是正确的选择。 后来，当几乎有可能被纳入时，我对此失去了兴趣，宁愿让
它保持这种状态，部分是出于沮丧，部分是为了
保持对 Stackless 的控制。
像“其他实现无法做到这一点”这样的论点对我来说总是很蹩脚，因为还有其他例子也可以使用这个论点。 我想我最好忘记这一点，并与 Guido 保持良好的友谊，拥有自己的发行版。
与此同时，事情再次发生变化。 我正在研究 PyPy 和 Stackless 作为扩展 有时稍后会谈论这个
干杯 - Chris
it took quite long to find this discussion. At that
time I was not on PyPy but had a 2-years affair with psyco, until health stopped this all quite abruptly. I'm now active again and designing an
alternative approach - will present it on EuroPython 2012.
Most of Andrews statements are correct. Some
minor additions:
Stackless was significantly faster than CPython, 10 years ago, because I optimized the interpreter loop. At that time, Guido was not ready for that. A few years later, people did similar optimizations and even more and better ones, which makes Stackless a little bit slower, as expected.
On inclusion: well, in the beginning I was very pushy and convinced that Stackless is the way to go. Later, when it was almost possible to get included, I lost interest in that and preferred to let
it stay this way, partially out of frustration, partially to
keep control of Stackless.
The arguments like "other implementations cannot do it" felt always lame to me, as there are other examples where this argument could also be used. I thought I better forget about that and stay in good friendship with Guido, having my own distro.
Meanwhile things are changing again. I'm working on PyPy and Stackless as an extension Will talk about that sometimes later
Cheers -- Chris
如果我没记错的话，Stackless 原本计划纳入官方 CPython，但 Stackless 的作者告诉 CPython 人员不要这样做，因为他计划对代码库进行一些重大更改 - 大概他希望稍后再进行集成该项目更加成熟。
If I recall correctly, Stackless was slated for inclusion into the official CPython, but the author of stackless told the CPython folks not to do so, because he planned to do some significant changes to the code base - presumeably he wanted the integration done later when the project was more mature.
我也对这里的答案感兴趣。 我玩过一些 Stackless，看起来它将是对标准 Python 的一个很好的补充。
PEP 219 确实提到了如果 Python 想要更改为不同的堆栈，则从 C 代码调用 Python 代码可能会遇到困难。 需要有一些方法来检测和防止这种情况（以避免破坏 C 堆栈）。 我认为这很容易处理，所以我也想知道为什么 Stackless 必须独立存在。
I'm also interested in the answers here. I've played a bit with Stackless and it looks like it would be a good solid addition to standard Python.
PEP 219 does mention potential difficulties with calling Python code from C code, if Python wants to change to a different stack. There would need to be ways to detect and prevent this (to avoid trashing the C stack). I think this is tractable though, so I'm also wondering why Stackless must stand on its own.