您对Google 的 Unladen Swallow有何看法和期望？从他们的项目计划中：
我们想让 Python 更快，但我们也想让大型、完善的应用程序更容易切换到 Unladen Swallow。
- 生成 Python 版本至少比 CPython 快 5 倍。
- Python 应用程序性能应该是稳定的。
- 保持与 CPython 应用程序的源代码级兼容性。
- 保持与 CPython 扩展模块的源代码级兼容性。
- 我们不想永远维护一个 Python 实现；我们将我们的工作视为一个分支，而不是一个分支。
甚至更甜蜜：
此外，我们打算移除 GIL 并修复 Python 中的多线程状态。我们相信这可以通过实施更复杂的 GC 来实现
它看起来好得令人难以置信，就像 PyPy 和 Stackless 的最佳组合一样。
更多信息：
更新：正如 DNS 指出的那样，有一个相关的问题：什么是 LLVM 以及如何用 LLVM 替换 Python VM 将速度提高 5 倍？
我对它寄予厚望。
谷歌的几个人正在研究这个问题。鉴于 BDFL 也在那里使用，这是一个积极的方面。
他们立即声明这是一个分支，而不是一个叉子。因此，这有可能最终被合并到主干中。
最重要的是，他们有一个工作版本。他们现在正在为 Youtube 的内容使用一个空载燕子版本。
他们似乎有他们的狗屎在一起。他们在这个阶段有一个相对详细的项目计划，他们有一个测试列表，用于衡量性能改进和回归。
我对 GIL 的移除并没有屏住呼吸，但即使他们从来没有解决这个问题，单单速度的增加就让它变得很棒。
很抱歉让您失望了，但是当您阅读PEP 3146时，情况看起来很糟糕。
到目前为止，改进很小，因此编译器代码变得更加复杂。删除 GIL 也有许多缺点。
Btw. PyPy seems to be faster then Unladen Swallow in some tests.
我认为该项目具有崇高的目标，并且有足够的时间（2-3 年），它们可能会实现其中的大部分。
他们可能无法将他们的分支合并回主干，因为 Guido 目前的观点是 cpython 应该是一个参考实现（即它不应该做 IronPython 和 jython 无法复制的事情。）我看过报告这就是阻止 stackless 的酷部分被合并到 cpython 中的原因。
这个问题讨论了许多相同的事情。我的意见是听起来不错，但我在等着看它是什么样子，以及需要多长时间才能稳定下来。
我特别关心与现有代码和库的兼容性，以及库编写社区如何响应它。最终，除了个人爱好项目之外，它对我来说是零价值，直到它可以运行我所有的第三方库。
Guido 刚刚在他的推特账户上发布了一篇文章，这是对之前发布的 Jesse Noller 文章的更新。 http://jessenoller.com/2010/01/06/unladen-swallow-python-3s-best-feature/。听起来他们正在像前面提到的 python 3 一样前进。
他们有一个季度发布。所以就在不远处，观望，让他们想出一些不只是计划的东西。
如果它确实是真的，那么即使对于性能密集型操作，也很容易摆脱 C 和 C++。
即使它是 Google 赞助的开源项目，令人惊讶的是，它在任何地方都没有涉及 Guido。
我认为 5 倍的速度提升对我个人来说并不是那么重要。
这不是一个数量级的变化。尽管如果您消耗的 CPU 功率与 Google 的规模相当，那么让您的一些员工参与其中可能是值得的投资。
许多速度改进最终可能会使其进入 cpython。
摆脱 GIL 原则上很有趣，但一旦 GIL 被删除，可能会暴露出许多与非线程安全的模块有关的问题。
我不认为我会很快使用 Unladen Swallow，但喜欢关注性能如何改进常规 Python 版本。