为什么 PyPy 没有包含在标准 Python 中？

小开

首先，它是带有 Python 2.x 的不是100% 相容，并且在3.x 中只有初步支持。

它也不是可以合并的东西—— PyPy 提供的 Python 实现是使用他们创建的框架生成的，这个框架非常酷，但是与现有的 CPython 实现完全不同。它必须是完全替代的。

PyPy 和 CPython 之间有一些非常具体的分歧，其中一个很重要的问题就是如何支持扩展模块——如果您想要超越标准库，这是一个很重要的问题。

同样值得注意的是，PyPy 并不是普遍地更快。

小开

一个原因可能是，根据 PyPy站点，它目前只能在32位和64位 Intel x86架构上运行，而 CPython 也能在其他平台上运行。这可能是由于 PyPy 中特定于平台的速度增强。虽然速度是一件好事，但人们通常希望语言实现尽可能“与平台无关”。

小开

参见这个吉多·范罗苏姆的视频。他在12分33秒的时候谈到了你问的同一个问题。

亮点:

缺乏 Python 3兼容性
缺乏扩展支持
不适合作为胶水代码
速度不是一切

毕竟，他才是那个决定..。

小开

最佳答案

PyPy 不是 CPython 的分支，因此它不能直接合并到 CPython 中。

从理论上讲，Python 社区可以普遍采用 PyPy，PyPy 可以作为参考实现，而 CPython 可以中止。然而，PyPy 也有自己的弱点:

CPython 很容易与用 C 编写的 Python 模块集成，这是传统的 Python 应用程序处理 CPU 密集型任务的方式(参见 SciPy 项目)。
PyPy JIT 编译步骤本身占用 CPU 时间——只有通过重复运行已编译的代码，总体来说才会变得更快。这意味着启动时间可能更长，因此 PyPy 对于运行粘合代码或普通脚本不一定那么有效。
PyPy 和 CPython 的行为在各个方面并不完全相同，特别是在涉及到“实现细节”(未由语言指定但在实际层面仍然重要的行为)时。
CPython 运行在比 PyPy 更多的体系结构上，并且已经成功地适应了在嵌入式体系结构中运行的方式，这对 PyPy 来说可能是不切实际的。
CPython 用于内存管理的引用计数方案可以说比 PyPy 的各种 GC 系统具有更可预测的性能影响，尽管这不一定适用于所有“纯 GC”策略。
PyPy 还不完全支持 Python 3.x，尽管它是一个活动的工作项。

PyPy 是一个伟大的项目，但 CPU 密集型任务的运行速度并不是一切，在许多应用程序中，它是最不值得关注的问题。例如，Django 可以在 PyPy 上运行，这使得模板更快，但是 CPython 的数据库驱动程序比 PyPy 的更快; 最终，哪个实现更有效取决于给定应用程序的瓶颈在哪里。

另一个例子: 您可能认为 PyPy 对于游戏来说非常棒，但是大多数类似于 PyPy 中使用的 GC 策略会引起明显的抖动。对于 CPython，大部分 CPU 密集型的游戏内容都被卸载到 PyGame 库中，PyPy 无法利用这一点，因为 PyGame 主要是作为 C 扩展实现的(不过参见: PyGame-cffi)。我仍然认为 PyPy 是一个很好的游戏平台，但我从未见过它真正被使用过。

PyPy 和 CPython 对于基本的设计问题有着截然不同的方法，并且做出了不同的权衡，因此在任何情况下，两者都不是“更好”的。

小开

我建议观看大卫・比兹利的这个主题演讲，以获得更多的见解。它通过阐明 PyPy 的本质和复杂性来回答你的问题。

小开

除了这里已经说过的所有内容之外，PyPy 在 bug 方面远不如 CPython 那样坚如磐石。通过 SymPy，我们在过去的几年中在 PyPy 中发现了大约12个 bug，无论是在发布版本还是在晚间新闻中。

另一方面，我们在 CPython 中只发现了一个 bug，那是在一个预发布版本中。

另外，不要忽视对 Python 3的支持。在核心 Python 社区中，甚至没有人再关心 Python2了。他们正在致力于 Python 3.4的下一个重大事件，这将是 Python 3的第五个主要版本。PyPy 的人还没有得到他们中的一个。所以在他们开始成为竞争者之前，他们还有一些事情要做。

别误会。PyPy 太棒了。但是在很多重要的方面，它仍然远远不如 CPython。

顺便说一下，如果在 PyPy 中使用 SymPy，就不会看到更小的内存占用(或者加速)。参见 https://bitbucket.org/pypy/pypy/issues/1447/。