PyPy is Hard to UnderstandPyPy具有巨大的潜力,在这一点上,它与CPython高度兼容所以它能运行Flask,Django等等)。 但关于PyPy有许多困惑 (例如,荒谬的建议创造一种PyPyPy…语言). 按我的观点,那主要是因为PyPy实际上 是两种东西:一种用RPython (非Python (我之前撒谎了))编写的Python解释器。 RPython是Python的子 集,具有静态类型。在Python里,最难严格推论类型 (为什么这么困难,考虑下下面的事实:
只为清晰,我将引用这些PyPy(1)和PyPy(2)。 为什么你在同一层面下同时需要这两者? 你可以这样想一下:PyPy(1)是一个用RPython写的解释器,因此它 能加载用户的Python代码并将它编译成字节码。但是这个用RPython写的解释器本身要能运行,就必须要被另 外一个Python实现去解释,对不? 我们可以直接用CPython去运行这个解释器。但是这个还不够快 取而代之,我们使用了PyPy(2)(参考 RPython的工具链)去编译这个PyPy的解释器,生成其他平台(比如C, JVM或CLI)代码在我们的机器上运行,并且还加入了JIT特性。这个很神奇:PyPy动态的将JIT加入一个解释器, 生成它自己编译器!(这就是核心原理:我们在编译一个解释器,并同时加入了另外一个单独的编译器到里面去)。 最终结果就是一个融合了JIT优化特性的单独的可执行文件,用来解释执行我们的Python源代码。这就是我们之前 想要达到的效果。这么讲可能比较拗口,下面这张图可能会解释的比较清楚点: 再次重申下,PyPy真正可贵之处在于我们可以利用RPython实现各种不同的Python解释器,不用去关心JIT (除了一些小的提示外)。PyPy到时候会利用RPython工具链/PyPy(2)为我们自动实现JIT 事实上,我们还可以更抽象一点,我们理论上可以写一个适用于任何语言的解释器,然后将它扔给PyPy,最后 获得那种语言的JIT。原因是PyPy仅仅关心的是优化解释器,而不会去关心这个解释器到底解释的是什么语言。 理论上你自己可以写一个适用于任何语言的解释器,然后将这个解释器传给PyPy,最后你得到这个语言的一个 JIT。一个简单的题外话,我这里想提一下,JIT本事是相当棒的。它使用了一种叫做跟踪的技术, 按照下面的步骤执行:
想获取更多信息,可以参考这篇文章,易于理解,并且非常有趣 最后收尾:我们使用PyPy的RPython-to-C(或者其他目标平台)编译器去编译PyPy的基于RPython实现的解释器。 结尾为什么它如此的伟大?为什么这个疯狂的想法值得我们去追求?我想Alex Gaynor已经在他的博客上面做了 很好的解释了:“[PyPy就是未来] 因为[它]提供了更快的速度,更大的灵活性,并且对于Python的成长也提 供了一个更好的平台” 总之:
附录: 其他一些你可能已经听过的名字
语言绑定
JavaScript 框架
英文原文:Why Are There So Many Pythons? |