我不知道维基上提到“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的培训,请随时与我联系!:)