Stackless Python的缺点有哪些?

136

最近我在阅读关于Stackless Python的内容,它似乎与普通的cPython相比有很多优势。它拥有无限递归、微线程、续体等很酷的功能,并且同时比cPython更快(如果Python wiki所说的话是真的话,速度可以提高10%),而且与cPython兼容(至少支持版本2.5、2.6和3.0)。

这些看起来几乎太好了。然而,TANSTAAFL,我没有看到Python社区对Stackless的热情,PEP 219也从未实现。为什么呢?Stackless有哪些缺点?Stackless的衣柜里隐藏着什么骨灰?

(我知道Stackless并不提供真正的并发,只是一种更容易以并发方式编程的方法。这并不真正困扰我。)

4个回答

172

我不知道维基上提到“Stackless比原版快10%”是从哪来的,但我也从未尝试过测量这些性能数据。我想不出Stackless有什么可以产生这么大差异的功能。

Stackless是一款神奇的工具,但存在一些组织/政治问题。

首先是历史问题。约10年前,Christian Tismer开始谈论最终成为Stackless的东西。他有一个想法,但很难解释他在做什么以及为什么人们应该使用它。这部分是因为他的背景没有涉及协同程序等思想的计算机科学培训,并且他的演示和讨论非常实现导向,对于那些不熟悉连续性的人来说,很难理解如何将其用作解决问题的方案。

因此,最初的文档质量很差。其中一些描述了如何使用它,最好的贡献者是第三方。在PyCon 2007上,我发表了一个关于“使用Stackless”的演讲,根据PyCon调查数据,效果不错。Richard Tew在收集这些数据、更新stackless.com和维护新Python版本的发布方面做得非常好。他是CCP Games的员工,开发了EVE Online游戏系统中必不可少的Stackless。

CCP games也是人们谈论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,这是一个Python的实现。他已经在PyPy中实现了Stackless功能,并认为它比Stackless本身优秀得多,并且认为PyPy是未来的方向。Tew维护Stackless,但他对倡导不感兴趣。我考虑过担任那个角色,但无法看到如何从中获得收入。

尽管如此,如果您想接受关于Stackless的培训,请随时与我联系!:)


43

找到这个讨论耗费了相当长的时间。当时我没有使用PyPy,而是与Psyco有了两年的恋情,直到健康问题突然中断了这一切。现在我又活跃起来了,并设计了一种替代方法——将在EuroPython 2012上展示。

安德鲁的大部分陈述都是正确的。某些小的补充:

10年前,由于我优化了解释器循环,Stackless比CPython快得多。当时,Guido还没有准备好。几年后,人们进行了类似的优化,甚至更多和更好的优化,这使得Stackless稍微慢一点,正如预期的那样。

关于包含:起初,我非常强势,坚信Stackless是正确的路线。后来,当它几乎可以被纳入时,我对此失去了兴趣,并更喜欢让它保持这种状态,部分原因是出于挫败感,部分原因是为了掌控Stackless。

像“其他实现不能做到”这样的论点对我来说总是很无聊,因为还有其他例子可以使用这个论点。我想我最好忘记这个,与Guido保持友好,并拥有自己的发行版。

与此同时,事情又在变化。我正在将PyPy和Stackless作为扩展来使用。稍后会谈到这个问题。

干杯——Chris


5
如果我没有记错的话,Stackless曾计划被纳入官方的CPython中,但Stackless的作者告诉CPython的开发者不要这么做,因为他计划对代码库进行一些重大更改-很可能是希望在项目更成熟后再进行集成。

1
来源是什么?我觉得这很有趣,但我显然不能仅凭你的话就相信你。如果你错了,而我开始谈论它有多有趣,那我会变得很傻。 - Devin Jeanpierre
2
非常好的观点。很抱歉我没有参考资料,因为这是在freenode上的#python irc对话中,但我确实找到了一封古老的邮件列表对话,网址为http://gnosis.cx/download/charming_python_10_outtakes.html,其中提供了更多关于情况的见解。 - Arafangion
那个链接真的很棒。它回答了我很多的问题。 - Ryszard Szopa
那个链接已经有8或9年的历史了(它谈论的是Python 2.1),对于代码库未来变更的讨论早已结束。Stackless Python是稳定和成熟的,目前没有计划对“代码库进行重大更改”。 - Andrew Dalke
dalke:事情就是这样——如果有任何决定整合更改的实质性变化,请随时提供更新的参考资料,但我怀疑我提供的古老来源仅仅是开始了拥有不同变体的Python的趋势,例如JPython、IronPython等。 - Arafangion
(更新:dalke关于stackless的最新回答比我的好多了) - Arafangion

3

我也对这里的答案很感兴趣。我已经尝试过Stackless,它看起来是标准Python的一个很好的稳定补充。

PEP 219提到了从C代码调用Python代码可能存在的潜在困难,如果Python想要切换到不同的堆栈。需要有方法来检测和防止这种情况(以避免破坏C堆栈)。我认为这是可行的,所以我也想知道为什么Stackless必须独立存在。


3
PEP219已经有9年历史了,已经严重过时。在PEP中讨论的实现方式“从C代码调用Python代码”的困难只存在于讨论的实现中,而不是在Stackless中。PEP的名称(“无栈Python”)有点误导人,它从Stackless中汲取灵感,但仅此而已。 - Andrew Dalke

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接