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

Why wasn't PyPy included in standard Python?

提问by KLee1

I was looking at PyPyand I was just wondering why it hasn't been adopted into the mainline Python distributions. Wouldn't things like JIT compilation and lower memory footprint greatly improve the speeds of all Python code?

我在看PyPy，我只是想知道为什么它没有被主流 Python 发行版采用。像 JIT 编译和更低的内存占用这样的事情不会大大提高所有 Python 代码的速度吗？

In short, what are the main drawbacks of PyPy that cause it to remain a separate project?

简而言之，PyPy 的主要缺点是什么导致它仍然是一个独立的项目？

采纳答案by Andrew Gorcester

PyPy is not a fork of CPython, so it could never be merged directly into CPython.

PyPy 不是 CPython 的分支，因此它永远无法直接合并到 CPython 中。

Theoretically the Python community could universally adopt PyPy, PyPy could be made the reference implementation, and CPython could be discontinued. However, PyPy has its own weaknesses:

理论上，Python 社区可以普遍采用 PyPy，PyPy 可以作为参考实现，CPython 可以停止使用。但是，PyPy 有其自身的弱点：

• CPython is easy to integrate with Python modules written in C, which is traditionally the way Python applications have handled CPU-intensive tasks (see for instance the SciPy project).
• The PyPy JIT compilation step itself costs CPU time -- it's only through repeated running of compiled code that it becomes faster overall. This means startup times can be higher, and therefore PyPy isn't necessarily as efficient for running glue code or trivial scripts.
• PyPy and CPython behavior is not identical in all respects, especially when it comes to "implementation details" (behavior that is not specified by the language but is still important at a practical level).
• CPython runs on more architectures than PyPy and has been successfully adapted to run in embedded architectures in ways that may be impractical for PyPy.
• CPython's reference counting scheme for memory management arguably has more predictable performance impacts than PyPy's various GC systems, although this isn't necessarily true of all "pure GC" strategies.
• PyPy does not yet fully support Python 3.x, although that is an active work item.

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

PyPy is a great project, but runtime speed on CPU-intensive tasks isn't everything, and in many applications it's the least of many concerns. For instance, Django can run on PyPy and that makes templating faster, but CPython's database drivers are faster than PyPy's; in the end, which implementation is more efficient depends on where the bottleneck in a given application is.

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

Another example: you'd think PyPy would be great for games, but most GC strategies like those used in PyPy cause noticeable jitter. For CPython, most of the CPU-intensive game stuff is offloaded to the PyGame library, which PyPy can't take advantage of since PyGame is primarily implemented as a C extension (though see: pygame-cffi). I still think PyPy can be a great platform for games, but I've never seen it actually used.

另一个例子：您可能认为 PyPy 非常适合游戏，但大多数 GC 策略（如 PyPy 中使用的那些）会导致明显的抖动。对于 CPython，大部分 CPU 密集型游戏内容都卸载到 PyGame 库中，PyPy 无法利用这些内容，因为 PyGame 主要是作为 C 扩展实现的（尽管参见：pygame-cffi）。我仍然认为 PyPy 可以成为一个很好的游戏平台，但我从未见过它实际使用过。

PyPy and CPython have radically different approaches to fundamental design questions and make different tradeoffs, so neither one is "better" than the other in every case.

PyPy 和 CPython 对基本设计问题采用完全不同的方法并进行不同的权衡，因此在每种情况下，没有一个比另一个“更好”。

回答by Gareth Latty

For one, it's not 100% compatiblewith Python 2.x, and has only preliminary supportfor 3.x.

一方面，它与 Python 2.x并非 100% 兼容，并且仅初步支持3.x。

It's also not something that could be merged - The Python implementation that is provided by PyPy is generated using a framework they have created, which is extremely cool, but also completely disparate with the existing CPython implementation. It would have to be a complete replacement.

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

There are some very concrete differencesbetween PyPy and CPython, a big one being how extension modulesare supported - which, if you want to go beyond the standard library, is a big deal.

PyPy 和 CPython 之间有一些非常具体的区别，一个很大的区别是扩展模块的支持方式——如果你想超越标准库，这是一个大问题。

It's also worth noting that PyPy isn't universally faster.

还值得注意的是，PyPy 并不是普遍更快。

回答by Bitwise

One reason might be that according to PyPysite, it currently runs only on 32- and 64-bit Intel x86 architecture, while CPython runs on other platforms as well. This is probably due to platform-specific speed enhancements in PyPy. While speed is a good thing, people often want language implementations to be as "platform-independent" as possible.

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

回答by none

See this video by Guido van Rossum. He talks about the same question you asked at 12 min 33 secs.

观看Guido van Rossum 的这个视频。他谈到了你在 12 分 33 秒时问的同样问题。

Highlights:

强调：

• lack of Python 3 compatibility
• lack of extension support
• not appropriate as glue code
• speed is not everything

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

After all, he's the one to decide...

毕竟，他是决定的人……

回答by Abhishek Mishra

I recommend watching this keynote by David Beazleyfor more insights. It answers your question by giving clarity on nature & intricacies of PyPy.

我建议您观看David Beazley 的主题演讲以获取更多见解。它通过阐明 PyPy 的性质和复杂性来回答您的问题。

回答by asmeurer

In addition to everything that's been said here, PyPy is not nearly as rock solid as CPython in terms of bugs. With SymPy, we've found at about a dozen bugs in PyPy over the past couple of years, both in released versions and in the nightlies.

除了这里所说的所有内容之外，PyPy 在 bug 方面并不像 CPython 那样坚如磐石。使用 SymPy，我们在过去几年中在 PyPy 中发现了大约十几个错误，无论是在发布版本中还是在夜间。

On the other hand, we've only ever found one bug in CPython, and that was in a prerelease.

另一方面，我们只在 CPython 中发现了一个错误，而且是在预发布版中。

Plus, don't discount the lack of Python 3 support. No one in the core Python community even cares about Python 2 any more. They are working on the next big things in Python 3.4, which will be the fifth major release of Python 3. The PyPy guys still haven't gotten one of them. So they've got some catching up to do before they can start to be contenders.

另外，不要忽视缺乏 Python 3 支持。核心 Python 社区中的任何人都不再关心 Python 2。他们正在研究 Python 3.4 中的下一个重要内容，这将是 Python 3 的第五个主要版本。 PyPy 的人仍然没有得到其中一个。因此，在开始成为竞争者之前，他们还有一些工作要做。

Don't get me wrong. PyPy is awesome. But it's still far from being better than CPython in a lot of very important ways.

不要误会我的意思。PyPy 很棒。但在很多非常重要的方面，它仍然远不及 CPython。

And by the way, if you use SymPy in PyPy, you won't see a smaller memory footprint (or a speedup either). See https://bitbucket.org/pypy/pypy/issues/1447/.

顺便说一句，如果你在 PyPy 中使用 SymPy，你不会看到更小的内存占用（或加速）。请参阅https://bitbucket.org/pypy/pypy/issues/1447/。