为什么PyPy不包含在标准Python中?

KLe*_*ee1 163 python pypy

我正在看PyPy,我只是想知道为什么它没有被采用到主线Python发行版中.不会像JIT编译和更低的内存占用大大提高所有Python代码的速度吗?

简而言之,PyPy的主要缺点是什么导致它仍然是一个单独的项目?

And*_*ter 246

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现在带有增量GC,因此可能更适合游戏. (6认同)
  • PyPy不适合运行脚本.它的启动时间与CPython几乎相同,其解释速度也相似. (4认同)

Gar*_*tty 62

首先,它与Python 2.x 不是100%兼容,并且只对3.x 有初步支持.

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

PyPy和CPython之间存在一些非常具体的差异,一个很大的区别就是如何支持扩展模块 - 如果你想要超越标准库,这是一个大问题.

值得注意的是,PyPy并不普遍更快.


non*_*one 52

观看Guido van Rossum的视频.他谈到了你在12分33秒时提出的同样问题.

强调:

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

毕竟,他是决定......

  • +1链接与直接链接到视频的相关部分!此外,还有一个非常真实的Guido van Rossum非正式民意调查+1"有多少人在生产中使用PyPy?......没有动手?*咳嗽*嗯,我想CPython还有希望." (3认同)

Bit*_*ise 14

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

  • 请注意,ARM后端"几乎在那里",[PowerPC后端](https://bitbucket.org/pypy/pypy/changesets/tip/branch%28%27ppc-jit-backend%27%29)是WIP.另请注意,这仅指JIT编译器,将JIT移植到新架构只需要为相对简单和低级别的IR实现代码生成器,仅此而已. (6认同)

Abh*_*hra 7

我建议观看David Beazley的这个主题演讲,以获得更多见解.它通过明确PyPy的性质和复杂性来回答您的问题.


asm*_*rer 6

除了这里所说的一切之外,PyPy在错误方面并不像CPython那样坚如磐石.使用SymPy,我们在过去的几年中发现了PyPy中的大约12个错误,包括发布版本和夜晚版本.

另一方面,我们只在CPython中发现了一个错误,那是一个预发行版.

另外,不要忽视缺乏Python 3支持.核心Python社区中没有人甚至更关心Python 2.他们正在研究Python 3.4中的下一个重大事项,这将是Python 3的第五个主要版本.PyPy的人还没有得到其中一个.因此,在他们开始成为竞争者之前,他们已经有了一些赶超的事情.

别误会我的意思.PyPy太棒了.但它在很多非常重要的方面仍然远远不比CPython好.

顺便说一句,如果你在PyPy中使用SymPy,你将看不到更小的内存占用(或者加速).请参阅https://bitbucket.org/pypy/pypy/issues/1447/.

  • 截至2018年,我可以确认我在不同的sympy用法中看到了大约一个数量级的加速 (2认同)