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).
我最近一直在阅读关于Stackless Python的文章，与普通的cPython相比，它似乎有很多优势。它具有无限递归、微线程、延续等所有的酷特性，同时比cPython(如果相信Python wiki的话，大约是10%)更快，并且与之兼容(至少是2.5、2.6和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?
所有这些看起来都好得让人难以置信。然而，TANSTAAFL，我在Python社区中没有看到对Stackless的热情，并且PEP 219从来没有实现过。这是为什么呢?无堆叠的缺点是什么?什么骷髅藏在没有堆叠的壁橱里?
(I know Stackless doesn't offer real concurrency, just an easier way of programming in the concurrent way. It doesn't really bother me.)
(我知道Stackless并没有提供真正的并发性，而是一种更简单的并发编程方式。我真的不介意。
4 个解决方案
#1
153
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.
我不知道Wiki上的“Stackless is 10% faster where”是从哪里来的，但我也从未尝试过去衡量这些性能数据。我想不出Stackless做了什么来改变这么大的事情。
Stackless is an amazing tool with several organizational/political problems.
Stackless是一个有组织/政治问题的神奇工具。
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.
第一个来自历史。克里斯蒂安·蒂斯默(Christian Tismer)在大约10年前开始谈论最终变成了堆叠的东西。他知道自己想要什么，但很难解释他在做什么，以及人们为什么要用它。这在一定程度上是因为他的背景并没有接受过像coroutines这样的想法的CS培训，而且他的演讲和讨论都是以实现为导向的，这对于那些还没有深入研究的人来说，很难理解如何利用它来解决他们的问题。
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.
由于这个原因，最初的文档很糟糕。有一些关于如何使用它的描述，最好的来自第三方贡献者。根据PyCon的调查数据，在PyCon 2007年，我做了一个关于“使用Stackless”的演讲。Richard Tew在收集、更新stackless.com和维护新的Python发行版方面做得很好。他是CCP游戏公司(EVE Online)的一名员工，该公司将Stackless作为游戏系统的重要组成部分。
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.
CCP游戏也是人们在谈论Stackless时使用的最大的现实世界例子。Stackless的主要教程是Grant Olson的“使用Stackless Python并发编程入门”，这也是面向游戏的。我认为这让人们产生了一种扭曲的想法，认为Stackless是面向游戏的，而游戏更容易被继续导向。
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."
另一个困难是源代码。在最初的形式中，它要求对Python的许多部分进行修改，这使得Python的领头人圭多•范•罗索姆(Guido van Rossum)十分谨慎。我认为，部分原因是对call/cc的支持后来被删除，因为这“太像在有更好的高级表单时支持goto了”。我对这段历史不太确定，所以就把这段读作“Stackless曾经需要太多的改变”。
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.
稍后的版本不需要更改，Tismer继续推动将其包含在Python中。虽然有一些考虑，但官方的立场(据我所知)是，CPython不仅是一个Python实现，而且是一个引用实现，而且它不会包含无堆栈的功能，因为它不能由Jython或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.
绝对没有“对代码库进行重大更改”的计划。阿拉法特的引用和引用超链接(见评论)大约是在2000/2001年。结构上的改变已经做了很久，这就是我上面提到的。现在的Stackless是稳定的和成熟的，在过去的几年里只对代码库做了一些细微的调整。
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.
Stackless的最后一个限制是:没有人强烈主张Stackless。Tismer现在与PyPy密切相关，PyPy是Python对Python的实现。他在PyPy中实现了无堆叠功能，并认为它比无堆叠本身优越得多，并认为PyPy是未来的发展方向。Tew保持了无堆叠，但他对倡导不感兴趣。我考虑过担任这个角色，但不知道如何从中获得收入。
Though if you want training in Stackless, feel free to contact me! :)
虽然如果你想在Stackless训练，请随时联系我!:)
#2
36
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.
花了很长时间才找到这种讨论。当时我并不是在PyPy，而是和psyco有了两年的关系，直到健康停止了这一切。我现在又活跃起来，设计一种替代方法——将在2012年的EuroPython上展示。
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.
Stackless比10年前的CPython要快得多，因为我优化了解释器循环。当时，圭多还没有准备好。几年后，人们做了类似的优化，甚至更多更好的优化，这使得Stackless比预期的慢了一点。
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.
关于包容:嗯，一开始我很固执，并深信无堆叠是一种方法。后来，当我几乎有可能被包括进来时，我对它失去了兴趣，宁愿让它保持这种状态，部分出于沮丧，部分出于对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
与此同时，情况再次发生变化。我正在开发PyPy和Stackless作为扩展，稍后会讨论这个
Cheers -- Chris
干杯,克里斯
#3
4
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定于纳入到官方CPython的,但Stackless的作者告诉CPython的人不要这么做,因为他打算做一些重大的改变代码库——presumeably他想要集成完成后,项目更成熟。
#4
3
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.
我也对这里的答案感兴趣。我用Stackless做过一些游戏，它看起来是标准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.
PEP 219确实提到了从C代码调用Python代码的潜在困难，如果Python想要更改到另一个堆栈的话。需要有一些方法来检测和防止这种情况(以避免破坏C堆栈)。我认为这是可以处理的，所以我也想知道为什么Stackless必须独立存在。
#1
153
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.
我不知道Wiki上的“Stackless is 10% faster where”是从哪里来的，但我也从未尝试过去衡量这些性能数据。我想不出Stackless做了什么来改变这么大的事情。
Stackless is an amazing tool with several organizational/political problems.
Stackless是一个有组织/政治问题的神奇工具。
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.
第一个来自历史。克里斯蒂安·蒂斯默(Christian Tismer)在大约10年前开始谈论最终变成了堆叠的东西。他知道自己想要什么，但很难解释他在做什么，以及人们为什么要用它。这在一定程度上是因为他的背景并没有接受过像coroutines这样的想法的CS培训，而且他的演讲和讨论都是以实现为导向的，这对于那些还没有深入研究的人来说，很难理解如何利用它来解决他们的问题。
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.
由于这个原因，最初的文档很糟糕。有一些关于如何使用它的描述，最好的来自第三方贡献者。根据PyCon的调查数据，在PyCon 2007年，我做了一个关于“使用Stackless”的演讲。Richard Tew在收集、更新stackless.com和维护新的Python发行版方面做得很好。他是CCP游戏公司(EVE Online)的一名员工，该公司将Stackless作为游戏系统的重要组成部分。
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.
CCP游戏也是人们在谈论Stackless时使用的最大的现实世界例子。Stackless的主要教程是Grant Olson的“使用Stackless Python并发编程入门”，这也是面向游戏的。我认为这让人们产生了一种扭曲的想法，认为Stackless是面向游戏的，而游戏更容易被继续导向。
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."
另一个困难是源代码。在最初的形式中，它要求对Python的许多部分进行修改，这使得Python的领头人圭多•范•罗索姆(Guido van Rossum)十分谨慎。我认为，部分原因是对call/cc的支持后来被删除，因为这“太像在有更好的高级表单时支持goto了”。我对这段历史不太确定，所以就把这段读作“Stackless曾经需要太多的改变”。
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.
稍后的版本不需要更改，Tismer继续推动将其包含在Python中。虽然有一些考虑，但官方的立场(据我所知)是，CPython不仅是一个Python实现，而且是一个引用实现，而且它不会包含无堆栈的功能，因为它不能由Jython或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.
绝对没有“对代码库进行重大更改”的计划。阿拉法特的引用和引用超链接(见评论)大约是在2000/2001年。结构上的改变已经做了很久，这就是我上面提到的。现在的Stackless是稳定的和成熟的，在过去的几年里只对代码库做了一些细微的调整。
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.
Stackless的最后一个限制是:没有人强烈主张Stackless。Tismer现在与PyPy密切相关，PyPy是Python对Python的实现。他在PyPy中实现了无堆叠功能，并认为它比无堆叠本身优越得多，并认为PyPy是未来的发展方向。Tew保持了无堆叠，但他对倡导不感兴趣。我考虑过担任这个角色，但不知道如何从中获得收入。
Though if you want training in Stackless, feel free to contact me! :)
虽然如果你想在Stackless训练，请随时联系我!:)
#2
36
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.
花了很长时间才找到这种讨论。当时我并不是在PyPy，而是和psyco有了两年的关系，直到健康停止了这一切。我现在又活跃起来，设计一种替代方法——将在2012年的EuroPython上展示。
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.
Stackless比10年前的CPython要快得多，因为我优化了解释器循环。当时，圭多还没有准备好。几年后，人们做了类似的优化，甚至更多更好的优化，这使得Stackless比预期的慢了一点。
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.
关于包容:嗯，一开始我很固执，并深信无堆叠是一种方法。后来，当我几乎有可能被包括进来时，我对它失去了兴趣，宁愿让它保持这种状态，部分出于沮丧，部分出于对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
与此同时，情况再次发生变化。我正在开发PyPy和Stackless作为扩展，稍后会讨论这个
Cheers -- Chris
干杯,克里斯
#3
4
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定于纳入到官方CPython的,但Stackless的作者告诉CPython的人不要这么做,因为他打算做一些重大的改变代码库——presumeably他想要集成完成后,项目更成熟。
#4
3
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.
我也对这里的答案感兴趣。我用Stackless做过一些游戏，它看起来是标准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.
PEP 219确实提到了从C代码调用Python代码的潜在困难，如果Python想要更改到另一个堆栈的话。需要有一些方法来检测和防止这种情况(以避免破坏C堆栈)。我认为这是可以处理的，所以我也想知道为什么Stackless必须独立存在。