支持的Python版本

引用Python的禅意:

可读性。

例如，Python 3.8引入了fstring =。

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

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

问:如果与CPython相比，PyPy可以解决这些巨大的挑战(速度、内存消耗、并行性)，那么它的弱点是什么?

答:首先，几乎没有证据表明PyPy团队可以解决一般的速度问题。长期的证据表明，PyPy运行某些Python代码比CPython慢，这个缺点似乎深深植根于PyPy。

其次，在相当大的一组情况下，当前版本的PyPy比CPython消耗更多的内存。所以PyPy还没有解决内存消耗的问题。

PyPy是否解决了上面提到的巨大挑战，并且通常会比CPython更快，更少的内存消耗，对并行更友好，这是一个悬而未决的问题，短期内无法解决。有些人打赌，PyPy将永远无法提供一个通用的解决方案，使其在所有情况下都能主导CPython 2.7和3.3。

如果PyPy在总体上比CPython更好，这是值得怀疑的，影响其更广泛采用的主要弱点将是它与CPython的兼容性。还有一些问题，比如CPython在更广泛的cpu和操作系统上运行，但与PyPy的性能和CPython兼容性目标相比，这些问题要重要得多。

问:为什么我现在不能用PyPy替换CPython ?

答:PyPy并不是100%与CPython兼容，因为它没有在底层模拟CPython。一些程序可能仍然依赖于CPython的独特特性，而这些特性在PyPy中是不存在的，比如C绑定、Python对象和方法的C实现，或者CPython垃圾收集器的增量特性。

因为pypy不是100%兼容，需要8g的ram来编译，是一个移动的目标，并且是高度实验性的，其中cpython是稳定的，20年来模块构建器的默认目标(包括不能在pypy上工作的c扩展)，并且已经广泛部署。

Pypy可能永远不会成为参考实现，但它是一个很好的工具。

支持的Python版本

引用Python的禅意:

可读性。

例如，Python 3.8引入了fstring =。

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

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

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

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

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

第二个问题比较容易回答:如果所有代码都是纯Python，那么基本上可以使用PyPy作为替代。然而，许多广泛使用的库(包括一些标准库)是用C编写的，并编译为Python扩展。其中一些可以与PyPy一起工作，一些不能。PyPy提供了与Python相同的“面向”工具——也就是说，它是Python——但其内部结构不同，因此与这些内部结构交互的工具将无法工作。

至于第一个问题，我想这有点像第一个问题:PyPy一直在快速发展，以提高速度并增强与其他代码的互操作性。这使得它更像是实验性的，而不是官方的。

我认为，如果PyPy进入稳定状态，它可能会开始得到更广泛的应用。我还认为对Python来说，摆脱C语言的基础是一件很棒的事情。但这在一段时间内不会发生。PyPy还没有达到临界质量，它本身几乎足够有用，可以做你想做的所有事情，这将激励人们填补空白。