Stackless Python有什么缺点?[关闭]

问题:Stackless Python有什么缺点?[关闭]

我最近在阅读有关Stackless Python的文章,与普通cPython相比,它似乎具有许多优势。它拥有所有那些很酷的功能,比如无限递归地,微,延续等,并在同一时间比CPython的速度(10%左右,如果Python的维基是可信的),并用它(兼容至少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.)


回答 0

我不知道Wiki上的“ Stackless速度提高10%”来自何处,但是我再也没有尝试过衡量那些性能数字。我想不出Stackless所做的那么大的改变。

Stackless是一个出色的工具,它具有多个组织/政治问题。

首先来自历史。克里斯蒂安·蒂斯默(Christian Tismer)开始谈论大约10年前最终变成Stackless的事情。他对自己想要的东西有所了解,但是很难解释自己在做什么以及人们为什么要使用它。部分原因是他的背景没有接受有关协程等概念的CS培训,并且他的演示和讨论都非常注重实现,这对那些尚未深入研究延续性知识的人来说很难理解如何将其用作解决方案。他们的问题。

因此,最初的文档很差。其中有一些关于如何使用它的描述,其中有来自第三方贡献者的最好的描述。根据PyCon的调查数字,在PyCon 2007上,我发表了有关“ 使用无堆栈 ” 的演讲,该演讲进行得很顺利。理查德·图(Richard Tew)在收集这些内容,更新stackless.com以及在发布新的Python版本时保持发行版方面做得非常出色。他是EVE Online开发商CCP Games的雇员,该公司使用Stackless作为其游戏系统的重要组成部分。

CCP游戏也是人们在谈论Stackless时使用的最大的现实示例。Stackless的主要教程是Grant Olson的“ Stackless Python并发编程简介 ”,它也是面向游戏的。我认为这给人们带来了一个错误的想法,即Stackless是面向游戏的,而更多的是游戏更容易面向延续。

另一个困难是源代码。它的原始形式需要对Python的许多部分进行更改,这使得Python的领导者Guido van Rossum变得警惕。我认为部分原因是因为对call / cc的支持后来被删除,因为它“太像在拥有更好的高级表单时支持goto了”。我不确定这段历史,因此只需将本段读为“ Stackless曾经需要太多更改”。

以后的版本不需要更改,Tismer继续推动将其包含在Python中。尽管有一些考虑,但官方的立场(据我所知)是CPython不仅是Python实现,而且是参考实现,并且不包含Stackless功能,因为Jython无法实现或Iron Python。

绝对没有“ 对代码库进行重大更改 ”的计划。Arafangion的引用和参考超链接(请参阅评论)大约来自2000/2001。结构更改已经完成很长时间了,这就是我上面提到的。现在,无栈是稳定且成熟的,在过去几年中仅对代码库进行了少量调整。

Stackless的最后一个限制-没有强烈的主张Stackless。Tismer现在与PyPy紧密合作,PyPy是用于Python的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! :)


回答 1

找到这个讨论花了很长时间。那时我不在PyPy上,但是与psyco有两年的恋情,直到健康突然停止。我现在又很活跃,正在设计一种替代方法-将在EuroPython 2012上展示。

大多数安德鲁斯声明都是正确的。一些次要的补充:

Stackless比10年前的CPython快得多,因为我优化了解释器循环。那时,圭多还没有为此做好准备。几年后,人们做了类似的优化,甚至做了更多更好的优化,这使得Stackless的速度比预期的要慢一些。

关于包容性:嗯,一开始我很进取,并坚信Stackless是必经之路。后来,当几乎有可能将其包括在内时,我对此失去了兴趣,宁愿让它保持这种状态,部分是出于沮丧,部分是为了控制Stackless。

诸如“其他实现无法做到”之类的论点总是让我感到la脚,因为在其他示例中也可以使用此论点。我以为我最好忘记了这一点,并拥有自己的发行版,与Guido保持良好的友谊。

同时,情况再次发生变化。我正在研究PyPy和Stackless作为扩展,稍后会再讨论

干杯-克里斯

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


回答 2

如果我没记错的话,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.


回答 3

我对这里的答案也很感兴趣。我在Stackless上玩了一点,它看起来像是对标准Python的很好的补充。

如果Python要更改为其他堆栈,PEP 219确实提到了从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.