标签：des blog http io ar os 使用 sp java
Python 现在已经不仅仅是胶水脚本语言了. 不信？看看下面使用Python的成功案例:
要是你正在寻找快速介绍美丽的Python语言，我推荐My-Favorite-Python-Things
目前高级语言可以写出简单具有灵活性的代码. 所以在快速创建应用程序的时候是一个不错的选择, 你不需要花时间来处理各种数据类型 (所有接口示例代码都是为了满足编译处理). 可能有些人就会争论了，这个特性会产生有bug的代码. 但是 Guido van Rossum说:“生产的代码谁会不经过测试呢”? 静态语言在编译时期就能处理一些错误. 但这并不能检测出所有的错误. 最后你还是得编写测试代码。 而有这个时间完全可以为动态语言写出测试代码. 此外人们还不能设计一个堪称完美的类型系统. 对此Jim Treavor写了一些总结。
新技术允许我们为动态语言设计一个高效的运行环境 (JavaScript V8, LuaJIT, Racket, Common Lisp...), 这也可以和大型的框架竞争 (JVM, .NET, ...)
所有这一切都使得高级语言越来越流行得在大型企业和日常生活中使用。
现在Python非常流行，同时它的地位也受到竞争者的挑战。Python有良好的生态系统，也有大型软件和社区支持，但它缺乏其竞争者的高效和先进的运行环境。
正如我在开头说的一个特点，Python很容易连接各种编译库，这是它作为胶水语言在20年前流行的重要原因。但是目前依然活跃的工具已经很老旧了，你必须花大量精力才能使用它们。
相比之下，有很多新的工具能在相同的性能下（甚至超出），更好的处理这些任务。
胶水语言也有另一面。我们来想想底层高性能编程的过程。可能看起来会是下面几个过程：
感谢Python的简便性、脚本语言的本质和大量的工具，将他作为你代码的模板和核心。这就意味着你只需要写最少的底层代码，让Python做剩下的事：生成组织代码和你的底层代码需要的环境。
这与以往Lisp的理念一样，代码即数据，代码能够被其他正在执行的代码理解（代码可以作为数据被处理）。因而机器可以理解运行时正在执行的代码，并且去优化它，通过通常的方式就能得到全部的数据信息，而不用像C++那样使用模板。这是C++和其他流行的编程语言所没有的。最终我们有相对更底层的抽象级别，而运行时信息相对更丰富，使得编译器可以：
于是整个流程就好像这样：
就性能而言，这样的过程相比之前的方法有着更好的前景。
这些是已经用到这种方式的：PyPy, cffi, PyOpenCL, PyCUDA, numba, theano...
有很多方法能用Python写出高速的代码。最流行而且仍在广泛传播的方法是，用底层语言来写应用里最复杂的部分，然后使用，这对python来说无疑是很不幸的事。
所有Python里出色的高效的工具都需要许多复杂的c代码，这阻碍了其他的贡献者进来。现在我们想要写出高速而且美观的python代码。
有很多工具可以把python代码编译成机器代码，比如：Nuitka, Python2C, Shedskin, pythran。我认为它们都是失败的，当你使用它们的时候，就需要跟动态行为说再见了。他们只支持一部分的python语言，并且离完全支持还有很大距离。我甚至不认为以后他们能做到。另外他们也没有用那些使JIT（Just-In-Time 运行时编译执行）的解决方案变得出色的先进的技术和运行时信息。
这方面，Armins Rigo的文章写的很棒，可以参考：Multicore Programming in PyPy and CPython
为了让下一步的开发更简单，实现动态语言的最佳状态，Python需要一个合适的架构。当前CPython的架构过于简单，因而限制比较大，很难做到像JIT编译器那样的功能。下面是一些在增强CPython解释器性能上的失败的努力：
CPython最大的问题是他的C API，这部分没有很好的设计。其他部分的实现多少都受此影响。
- cffi - 简化对C库的应用
- cython - 编写可移植的C扩展。我并不推荐它用于通常的编程，不过它确实在维护C扩展方面更好一些，也更简单。Cython已经有CPython和PyPy后端。
PyPy为优化和进一步的语言开发提供了更好的架构。对于大部分Python已有的问题，PyPy已经提供了解决方案：
PyPy已经支持多平台 (x86, 64_x86, ARM)
PyPy同时还包含了一个优秀的现代的架构，在 Jim Huang 的演讲 中做了介绍，演讲的要点是：
相信让所有软件支持PyPy需要付出艰巨的努力 - 需要在现有的库上做很多工作。不过使用新的工具，编写支持PyPy和CPython的软件会比采用C扩展的方式更简单一些（在我们能做什么一节有介绍）。
现在来说一下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是你最终必须学习的编程语言
我希望PyPy当时并没有达到产品级可用。
关于本文的后续在Reddit上有一个有趣的讨论。这是关于在商业上应用PyPy的优缺点的讨论。讨论者总结了如何使用基于高性能库的PyPy。最重要的是使用PyPy软件栈（原始Python、cffi，等等）可以让维护和优化很简单（例如：延迟计算）。至于缺点，上面提到了，主要与CPython的遗留问题有关。
英文原文：The Python condition. Why PyPy is the future of Python
标签：des blog http io ar os 使用 sp java
原文地址：http://www.cnblogs.com/rrxc/p/4105099.html
