Children of a Lesser Python

许多年以来，人们期望提高程序的性能，尝试着为Python创建可选的虚拟机（alternative VM），然而无数次这样的努力都失败了。即使我们对那些犹如一只半死不活的、信奉巫术的部队一样仍蹒跚前行着的只完成一半的Python-to-Parrot翻译项目视而不见，而类似Mamba, Rattlesnake和 Vyper这些即将被遗忘、有着光鲜名字的项目仍成为了一个个纪念碑，矗立在追求更好VM性能的道路两旁。

同时，像pycore和ShedSkin一类新近的项目仍以类似于他们前辈的充满希望和乐观的态度不断地进行着发布。（大概一年前在Blog圈里发布得热热闹闹的pycore至今仍未有一个独立的发行版本出现，且未见任何动作）

似乎让Python运行速度快一些要比它看起来还要艰难。在考虑CPython实现的时候你没必要成为一个编译器或者VM设计专家并说什么“执行X太浪费了，我打赌你执行Y速度会更快些。”问题是这些人十有八九已经试过执行Y了并且在他们撞上南墙之前也许已经利用他们的设计让80%的Python跑起来了。

那道南墙实际上主要就是：80%Python不是Python，因为大家都使用剩余20%的某些部分。ShedSkin仍未落入与其他项目一同灭亡的境地的唯一原因就是，他巧妙地回避了这个问题，并且不是通过自命决不是一种“类Python（Python-like）”语言而做到的。然而，这就有有点像Monty Python和The Holy Grail的黑色骑士，坚持说他的缺胳臂短腿“只是皮外伤”。换句话说确实如此，但也没有太大意义。

另一方面，我们注意到可选的VMs实际上实现了Python语言，但并未（在很大程度上来说）试图在速度上超过CPython。Jython和IronPython实际上合理地实现了Python语言的全部形式（complete forms），但是从实际的角度来说它们是不同的平台。试图以让一个应用程序能够在CPython, Jython,和IronPython上面都跑起来为目标是毫无意义的，所以，在任何情况下只有纯Python库在实现的时候才是可移植的。

但是，正是非纯粹的Python库赋予了(C/J/Iron)Python当前绝大部分的价值！对于数据库访问，数字捣弄（number crunching，译者注：(指电脑)迅速进行大量复杂运算），GUI工具的接口或其他任何数以千计的用途，是C, Java或CLR的库让Python变得实用了。CPython主要是一种粘合语言（glue language），用于汇编来自于C库的程序。而Jython和IronPython从某种程度上来说是成功的，因为他们是用于汇编Java或CLR组件的粘合语言。而且由于他们的价值因素取决于别处，Jython,和IronPython无需完全实现CPython的语义，尽管他们在试图走得近一些。

虽然总的来看我会说IronPython程序的性能是否更好仍存在争议，IronPython实际上在一些Python程序性能微型基准（Python performance microbenchmarks）上完成了改进。当然，很好的度量这个仍是困难的，因为IronPython是不同的平台。例如，一个使用NumPy的大批量数字捣弄程序将不会在IronPython上运行，所以你如何来比较它们呢？

这把我们引向了CPython最核心的问题。如果CPython的价值在于今天可以使用它完成所有工作，那么CPython就要快到提高性能的尽头了。现在，大多数增强性能的提议都被拒绝了，原因就是他们以向后不兼容（back-incompatible）的方式改变了Pyrhon C的API。如果一个变化需要每个人都重写他们的C代码，这个语言最好不要再是Python了。简而言之，CPython并不是一个语言实现，与Java VM和库不同的是，它是一个API平台，。

我们常常寄希望于Python3000 -- Guido对Python经过彻底思考的大胆想象，无需考虑向后兼容。这里我们可以告别C API的过去，探索新的领域—我们大体是这样设想的。

然而就在最近，Guido收回了原计划，例举了进行中的Perl 6的雾件情况和Joel Spolsky针对重写旗舰产品的议论（译者注：雾件指开发完成前就开始作宣传的产品）。取而代之的是Python 3000变成了Python3.0。这并不是一次完全的重写，而仍是一个对现有语言进行调整的比较模糊的计划，摒弃了一些Guido过去认为是错误的东西。尽管将允许向后不兼容，但Guido仍宣称CPython的实现将不会从头开始重写。依旧不清楚的是这是否意味着我们可以通过被重写的第三方扩展的方式来进行重构。也许，这将取决于具体个案了

但是，正如可提出证据加以证明的那样，今天对于CPython平台存在的一个最大的问题就是缺少由语言和Python代码可表达性定义的一个外部函数（foreign function）接口。取而代之的是CPython总是依靠一个固定的C API来表达外部接口。从最初的想法出发—即一个Amoeba操作系统的嵌入式脚本语言--那是没什么问题的。但是，缺少C FFI就意味着像SWIG, Pyrex, ctypes, Boost::Python等等这样的工具得不得不出来弥补这个缺陷，可是他们对于Python来说没有一个是“标准”。所以一个给定的CPython扩展部分可以用它们中的任何一个或者不用它们来写。因此，今天便成了向后兼容性的拖累(ball-and-chain)：Python/C API。

另外，这些工具中很少有被设计成独立于现有CPython实现的。除了ctypes它们都有可指定一个生成代码的目标的功能。但是，Python语言定义的FFI将允许CPython API成为纯粹实现的细节，能够随一点点结论而改变。实际上，这样一个FFI具有更大的可移植性，即使对于Jython和 IronPython也是可用的。

然而，现在要把所有那些都解决为时已晚，抑或果真如此？

走进PyPy。两个月前，PyPy0.7发布了。一个重要的里程碑，PyPy0.7是第一个自足执行(self-hosting)的Python实现。它是一个Python的实现，用Python写的，并可以自行解释。另外，部分PyPy是一个翻译系统，它允许将Python代码翻译成其他语言，并且包含一种外联函数接口，虽然托Guido的福仍未被标准化。PyPy开发人员现在已经完成了除了作为高级Python代码的C平台特性的最小化之外重写的工作。简而言之，对于我们来说PyPy已经脱离CPython需要向后兼容C API的“引力井”并在这一方面又迈出了重要的一步。

怎么强调它的重要性也不为过。当前的CPython实现受困于许多设计决策，而对于PyPy不存在这个问题。举个简单的例子，PyPy可以生成本身支持线程和不支持线程的版本，本身的refcounting和垃圾回收的版本等等。本质上讲，PyPy关于底层VM是很实际的，即使它使用是CPython的字节码（bytecode）。所以，在未来几年里，VM将有可能在根本上进行重新设计的试验，而不会像过去的项目一样在“最后20%的问题”上陷入了困境。哎呀，应该很可能在每个应用程序基础上都可以使用定制的VMs！

另外，由于PyPy是用Python实现的，在它上面进行编程来改变目前的Python语言或者其语义将比在CPython上面编简单多了。简而言之，我们几乎是处于Python语言发展的入门阶段，并且正在远离可选实现（alternative-implementation）这条路。

       但是速度怎么样？PyPy目前描述为比CPython要慢200-300倍，这取决于你正在做什么和你将它翻译成什么样的VM。这听起来很糟糕，直到你看到这样一个事实：在CPython上面运行的、未经翻译的PyPy，在运行的时候要慢2000倍。这就意味着--如果你注意到--PyPy已经能够将Python代码转换成运行要快10倍的C代码！

       那是一项很大的改进。应当承认，存在问题的代码从技术上讲是“RPython”。这是一个Python有限子集，其不包含更加动态（more-dynamic）的特性。但是，他无须通过类型声明来提高速度，就像Pyrex一样。并且如果Stackless的领导人Christian Tismer能够在造一个RPython-to-CPython扩展模块翻译器的路上继续走下去，那么这种技术很快就可以应用到实际中去。

       所以，如果有可能从Python的子集中创建一个高效的C，那是不是意味着PyPy就完结了呢？我们难道就不能执行那个翻译过程并沿着这条路走下去吗？很不幸，答案是否定的。当然，虽然我们可以将那些速度快的模块放回到CPython平台，翻译过程仍旧十分缓慢，还需要将其本身进行加速。同样地，这也仍没有使CPython真正地快起来—这既是意味着我们可以先编译一些独立的模块以使他们运行速度更快一些。

       因而为了实现所承诺的目标，PyPy必须首先接近CPython的速度。只有当它越来越接近这个目标的时候，越来越多抱有加快程序速度想法的人们就将会对自己说：“我想知道是否可以让PyPy执行Y而不是X？”并且与现在CPython状况不同的是，他们用不着既是Python老师也是CPython VM专家才能有希望实现它。

       所以，新的VM并不会全部涌现出来之后便因其不完善而寿终正寝，取而代之的是，也许我们会很快见到一个相反的趋势：现存的VM逐渐衰败，替代它的是始终具备灵活性的PyPy。幸运的话，我们可能还会看到PyPy顶替以C、Java和C#作为翻译后端的CPython, Jython和IronPython的位置，成为了统治一切的Python平台（One Python to Rule Them All）。