为什么有这么多 Python?(1)(2)

IronPython是另一很流行的Python 实现，完全用C#实现，针对.NET平台。她运行在可以叫做.NET虚拟机的平台上，这是微软的 Common Language Runtime (CLR)，同JVM相对应。

你可能会说，Jython:Java::IronPython:C#。它们各自运行在相同的虚拟机上，你能从你的IronPython中导入C#的类，从你写的Jython代码中带入Java类，等等

你完全可以不用任何非CPython的实现就能完成你手 上的任何工作。但是使用这些技术也是有很多的好处的，大部分取决于你现在所使用的技术栈。 你使用了很多基于JVM的语言？Jython就是为你准备的。使用的都是.NET世界的语言？那么你应该试试IronPython了或许你已经在用了）

顺便说一下尽管这不是使用不同的实现的理由），注意Python的各种实现在对待你的Python源码的时候所做的处理方式是完全不一样的。然后这些差 异是很小的，由于这些实现都在不停的发展改进中，随着时间的推移，这些差异会慢慢融合和兼容。比如，IronPython默认情况下使用Unicode字 符串，但是在2.x版本的CPython中默认是ASCII字符串如果使用了非ASCII字符串，会抛出一个UnicodeEncodeError错 误），但是在3.x版本里面CPythong已经默认支持Unicode字符串了。

即时编译: PyPy和它的未来

我们已经有了一个使用C写的Python实现，一个用Java写的，一个用C#写的。接下来就是：用Python写的Python实现有心人可能会注意这句话有点问题，是个死循环，^_^）

接下来我们看下什么地方容易搞混淆。首先，我们讨论下即时编译器JIT

JIT: 为什么会有这个？它的原理是什么？

大家都知道本地机器码的速度比字节码的速度快很多。那么，如果我们能将一些字节码直接编译成本地机器码再去运行它会怎样呢？我们必须花费一些代价比如时 间）在编译字节码到本地机器码上，如果最终的运行时间更快，那么这个代价就是值得的。这就是JIT编译器的动机，一种混合了解释器和编译器好处的技术。简 单来讲，JIT就是想通过编译技术提升脚本解释器系统的速度。

例如, 被JIT及时编译）采用的通用方法:

这是关于PyPy的用处: 把JIT代入Python语言 (参看前面成果的附录).当然也有其他目的: PyPy 目标是成为一个跨平台，轻内存，支持stackless译注：stackless为python提供微线程扩展，具有并发特性）。 但是及时编译才是它真正的卖点。 基于一系列时间测试的平均, 据说性能上能提高6.27倍. 停一下, 看看下面这个由PyPy Speed Center提供的图表:

PyPy is Hard to Understand

PyPy具有巨大的潜力，在这一点上，它与CPython高度兼容所以它能运行Flask，Django等等）。

但关于PyPy有许多困惑 (例如，荒谬的建议创造一种PyPyPy…语言). 按我的观点，那主要是因为PyPy实际上是两种东西：

一种用RPython (非Python (我之前撒谎了))编写的Python解释器。 RPython是Python的子集，具有静态类型。在Python里，最难严格推论类型 (为什么这么困难，考虑下下面的事实：

x = random.choice([1, "foo"]) 

为什么你在同一层面下同时需要这两者？ 你可以这样想一下：PyPy(1)是一个用RPython写的解释器，因此它能加载用户的Python代码并将它编译成字节码。但是这个用RPython 写的解释器本身要能运行，就必须要被另外一个Python实现去解释，对不？

我们可以直接用CPython去运行这个解释器。但是这个还不够快

取而代之，我们使用了PyPy(2)参考 RPython的工具链） 去编译这个PyPy的解释器，生成其他平台比如C, JVM或CLI）代码在我们的机器上运行，并且还加入了JIT特性。这个很神奇：PyPy动态的将JIT加入一个解释器，生成它自己编译器！这就是核心 原理：我们在编译一个解释器，并同时加入了另外一个单独的编译器到里面去）。

最终结果就是一个融合了JIT优化特性的单独的可执行文件，用来解释执行我们的Python源代码。这就是我们之前想要达到的效果。这么讲可能比较拗口，下面这张图可能会解释的比较清楚点：