英文原文：The Python condition. Why PyPy is the future of Python 编译：oschina

Python 现在已经不仅仅是胶水脚本语言了。 不信？看看下面使用Python的成功案例：

• YouTube – 主要由 Python编写
• NASA
• Industrial Light & Magic Runs – 电影公司
• OpenStack
• Sage – 科学软件及其他 (SciPy, PythonXY)
• WEB框架 Django, Pyramid, bottle…
• 修订控制系统
• 其他不错的软件

要是你正在寻找快速介绍美丽的Python语言，我推荐 My-Favorite-Python-Things

高级语言是主流

目前高级语言可以写出简单具有灵活性的代码，所以在快速创建应用程序的时候是一个不错的选择，你不需要花时间来处理各种数据类型 (所有接口示例代码都是为了满足编译处理)，可能有些人就会争论了，这个特性会产生有bug的代码，但是 Guido van Rossum说：“生产的代码谁会不经过测试呢”？ 静态语言在编译时期就能处理一些错误，但这并不能检测出所有的错误。最后你还是得编写测试代码。 而有这个时间完全可以为动态语言写出测试代码。此外人们还不能设计一个堪称完美的类型系统，对此Jim Treavor写了一些总结。

新技术允许我们为动态语言设计一个高效的运行环境 (JavaScript V8, LuaJIT, Racket, Common Lisp…), 这也可以和大型的框架竞争 (JVM, .NET, …)

所有这一切都使得高级语言越来越流行得在大型企业和日常生活中使用。

Python能延续传奇吗？

现在Python非常流行，同时它的地位也受到竞争者的挑战。Python有良好的生态系统，也有大型软件和社区支持，但它缺乏其竞争者的高效和先进的运行环境。

相比之下，有很多新的工具能在相同的性能下（甚至超出），更好的处理这些任务。

• cffi – 一个能轻松处理你的c库的包。在接触硬件或者支持其他软件时你会经常做这样的事（像数据库客户端、驱动程序）。尝试下在python里使用它是多么简单吧。你不需要写任何的封装，类型化代码。而且还有 CPython 和 PyPy 的支持。
• bitey

这与以往Lisp的理念一样，代码即数据，代码能够被其他正在执行的代码理解（代码可以作为数据被处理）。因而机器可以理解运行时正在执行的代码，并且去优化它，通过通常的方式就能得到全部的数据信息，而不用像C++那样使用模板。这是C++和其他流行的编程语言所没有的。最终我们有相对更底层的抽象级别，而运行时信息相对更丰富，使得编译器可以：

• 为未知的硬件做特化 (编码时)，包括支持的数据类型，以及可用的优化方法。
• 自动调整（tuning） (例如为库提供的数据，如 ATLAS…)
• 推送更多的信息给编译器，得到更好的推理。
• 人们不用为数据类型烦恼（运行时环境就已经可以保证快速、正确使用数据类型）

于是整个流程就好像这样：

• 想法
• 一点Python代码（最棒的部分），用来构建整个架构。然后是一些底层的代码 ，同样很棒，因为这些代码没有恶心的模板和上下文代码。事实上，底层的代码也可以通过Python代码生成。
• 运行
• 调试，比起前面的步骤时间更短一些

就性能而言，这样的过程相比之前的方法有着更好的前景。

这些是已经用到这种方式的：PyPy, cffi, PyOpenCL, PyCUDA, numba, theano…

解释器的设计

为了让下一步的开发更简单，实现动态语言的最佳状态，Python需要一个合适的架构。当前CPython的架构过于简单，因而限制比较大，很难做到像JIT编译器那样的功能。下面是一些在增强CPython解释器性能上的失败的努力：

• psyco (被PyPy代替)
• Unladen swallow
• 消除GIL的很多失败的尝试
• 还有一些尝试修复CPython一些缺陷的尝试: Stackless和HotPy，但是Guido (Python之父，仁慈的独裁者) 的坚持使得这些项目没有被合并到Python中。（说明一下，HotPy还不是产品级的东西）。

CPython最大的问题是他的C API，这部分没有很好的设计。其他部分的实现多少都受此影响。

PyPy同时还包含了一个优秀的现代的架构，在 Jim Huang 的演讲 中做了介绍，演讲的要点是：

• 解释性语言的框架
• 用于研究和产品的组件组合 (不同的数据模型，垃圾回收 – 这些可以在具体的应用场景进行改变)
• 构建在基于组件链的功能架构之上(翻译工具链)。每一个步骤都会延续/转换程序模型、引入特征、各种后端（JVM, JavaScript, LLVM, GCC IR等等)。来看一下翻译链的例子：python 代码 -> 字节码 -> 函数对象 -> 类型推断 -> 垃圾收集器 -> JIT
• 包含大量在架构的不同层次开发的现代的优化技术 (这个任务可以简化)

相信让所有软件支持PyPy需要付出艰巨的努力 – 需要在现有的库上做很多工作。不过使用新的工具，编写支持PyPy和CPython的软件会比采用C扩展的方式更简单一些（在我们能做什么一节有介绍）。

CPython遗留问题

现在来说一下CPython依赖性代码的遗留问题 (源于它们紧密依赖 c 扩展)。 这些主要是科学相关的软件 (NumPy, SciPy 等等)。Python在PyPy成为产品级软件之前早就被用于科学计算（我认为实在2年之前），之后这些软件在工具、代码和社区方面都得到很多发展。这些软件一起构建了一个很棒的平台，通常被用来作为Matlab之类的软件的替换（有人甚至认为是更好的选择）。要实现这些，C扩展是目前唯一的解决方案。现在，这些软件的发展仍然与CPython紧密绑定，因为要让科学计算相关的软件全部支持PyPy，需要大量的工作。近似的方案是使用按需执行的JIT – 对特定的函数做修饰，然后动态的把它们编译成机器码并切换到使用c扩展。这个想法不需要重写所有的科学计算的平台，而速度同样快速。采用这种方式的典型项目是numba，这是由Continuum Analytics (这家公司主要发布基于python库的强壮的科学计算平台)赞助的。Numba采用这种方式是因为它的快速脚本需要与其他依赖CPython的科学计算代码兼容。numba值得学一下，SciPy会议的numba演讲 是一个很好的阐述。

不得不说Python的科学计算社区非常棒。他们非常关注于质量、易用性和推广他们的产品（为此组织了很多会议：SciPy大会，PyData等）。感谢他们让Python成为免费的科学分析平台的首选。这里还需要提一下Travis Oliphant，他在社区中付出了很多努力，让整个平台协调一致。关于这些可以看一下这篇博客文章：为何Python是你最终必须学习的编程语言