该网站并没有声称PyPy比CPython快6.3倍。引用:

所有基准测试的几何平均值比CPython快0.16或6.3倍

这是一个与您所做的概括性陈述非常不同的陈述，当您理解其中的区别时，您将至少理解为什么不能只说“使用PyPy”的一组原因。这听起来像是我在挑刺，但理解为什么这两种说法完全不同是至关重要的。

具体来说:

他们的陈述只适用于他们使用过的基准测试。它完全没有说明您的程序(除非您的程序与他们的一个基准测试完全相同)。 这个陈述是关于一组基准的平均值。即使是他们测试过的程序，也没有人声称运行PyPy会带来6.3倍的改进。 没有人声称PyPy能运行CPython运行的所有程序，更不用说更快了。

注意:与2013年提出这个问题时相比，现在的PyPy更成熟，支持也更好。避免从过时的信息中得出结论。

PyPy, as others have been quick to mention, has tenuous support for C extensions. It has support, but typically at slower-than-Python speeds and it's iffy at best. Hence a lot of modules simply require CPython. PyPy doesn't support numpy. Some extensions are still not supported (Pandas, SciPy, etc.), take a look at the list of supported packages before making the change. Note that many packages marked unsupported on the list are now supported. Python 3 support is experimental at the moment. has just reached stable! As of 20th June 2014, PyPy3 2.3.1 - Fulcrum is out! PyPy sometimes isn't actually faster for "scripts", which a lot of people use Python for. These are the short-running programs that do something simple and small. Because PyPy is a JIT compiler its main advantages come from long run times and simple types (such as numbers). PyPy's pre-JIT speeds can be bad compared to CPython. Inertia. Moving to PyPy often requires retooling, which for some people and organizations is simply too much work.

我想说，这些是影响我的主要原因。

PyPy已经有Python 3支持一段时间了，但根据Anthony Shaw 2018年4月2日在HackerNoon发布的这篇文章，PyPy3仍然比PyPy (Python 2)慢几倍。

对于许多科学计算，特别是矩阵计算，numpy是更好的选择(参见常见问题:应该安装numpy还是numpypy?)

Pypy不支持gmpy2。您可以使用gmpy_cffi，不过我还没有测试它的速度，该项目在2014年发布了一个版本。

对于Project Euler问题，我经常使用PyPy，对于简单的数值计算，通常从__future__导入除法就足以满足我的目的，但截至2018年，Python 3支持仍在开发中，最好的选择是在64位Linux上。截至2018年12月的最新版本Windows PyPy3.5 v6.0处于测试阶段。

支持的Python版本

引用Python的禅意:

可读性。

例如，Python 3.8引入了fstring =。

Python 3.8+中可能有其他对您更重要的特性。PyPy目前不支持Python 3.8+。

无耻的自我广告:Python版本的杀手特性-如果你想知道更多你使用旧Python版本时错过的东西

I did a small benchmark on this topic. While many of the other posters have made good points about compatibility, my experience has been that PyPy isn't that much faster for just moving around bits. For many uses of Python, it really only exists to translate bits between two or more services. For example, not many web applications are performing CPU intensive analysis of datasets. Instead, they take some bytes from a client, store them in some sort of database, and later return them to other clients. Sometimes the format of the data is changed.

BDFL和CPython开发人员是一群非常聪明的人，他们设法帮助CPython在这种情况下表现出色。这是一个无耻的博客:http://www.hydrogen18.com/blog/unpickling-buffers.html。我使用的是Stackless，它源自CPython，并保留了完整的C模块接口。在这种情况下，我没有发现使用PyPy的任何优势。

CPython有引用计数和垃圾收集，PyPy只有垃圾收集。

因此，对象倾向于更早地删除，并且在CPython中以更可预测的方式调用__del__。有些软件依赖于这种行为，因此它们还没有准备好迁移到PyPy。

其他一些软件可以同时使用这两种方法，但使用CPython时使用的内存更少，因为未使用的对象会更早释放。(我没有任何测量方法来表明这有多重要，以及其他哪些实现细节会影响内存使用。)