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


127

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

所有这些看起来都太好了,难以置信。但是,TANSTAAFL,我在Python社区中没有看到对Stackless的热情,PEP 219从未实现。这是为什么?Stackless的缺点是什么?Stackless壁橱中隐藏着哪些骨架?

(我知道Stackless不提供真正的并发性,只是一种更简单的并发编程方式。它并没有真正打扰我。)

Answers:


165

我不知道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中进行培训,请随时与我联系!:)


39

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

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

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

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

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

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

干杯-克里斯


5

如果我没记错的话,Stackless计划列入官方的CPython中,但是stackless的作者告诉CPython人士不要这样做,因为他计划对代码库进行一些重大更改-大概他想在以后的时候完成集成该项目更加成熟。


1
资源?我觉得这很有趣,但显然不能仅仅因为您说的而相信您。如果您错了,我会看起来很傻,我开始谈论它有多有趣。
Devin Jeanpierre 09年

2
好点。对不起,我不具备参考,因为它是在freenode上#python一个IRC交谈,但是我还是设法找到一个古老的邮件列表谈话gnosis.cx/download/charming_python_10_outtakes.html这给了很多更深入的情况。
Arafangion

该链接确实很棒。它回答了我很多问题。
Ryszard Szopa

该链接已有8或9年的历史(它谈论的是Python 2.1),并且有关代码库未来更改的任何讨论都已经发生了很长时间。无堆栈Python是稳定且成熟的,并且没有“对代码库进行重大更改”的计划。
2009年

dalke:事情就是这样的-如果对整合变更的任何决定进行了实质性更改,请随时提出新的参考,但是我怀疑我提供的古老资料仅仅是开始形成具有单独变体的趋势蟒蛇,例如,JPython的,IronPytion ..
Arafangion

3

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

如果Python要更改为其他堆栈,PEP 219确实提到了从C代码调用Python代码的潜在困难。需要有检测和防止这种情况的方法(以避免浪费C堆栈)。我认为这很容易处理,所以我也想知道为什么Stackless必须独立。


3
PEP 219年9岁,严重过时了。“从C代码调用Python代码”的困难仅在PEP中讨论的实现中,而在Stackless中则没有。PEP(“无堆栈Python”)的名称有点用词不当;它从Stackless那里汲取了灵感,仅此而已。
Andrew Dalke 09年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.