为什么有这么多 Python?
2015-01-27 16:01
344 查看
英文原文:Why Are There So Many Pythons?
参与翻译(4人):一刀, 青崖白鹿, 嘉陵江的小鱼, yfwz100
仅中文 | 中英文对照 | 仅英文 | 打印此文章
Python是出类拔萃的 然而,这是一句非常模棱两可的话。这里的"Python"到底指的是什么? 是Python的抽象接口吗?是Python的通用实现CPython吗(不要把CPython跟Cython搞混了)?亦或者指的完全是其他的东西呢?可能我另外指的是Jython,或者IronPython,或者是PyPy。也或者转而谈论的又是RPython或者RubyPython(这两者是完全不同的东西)。 上面提到的那些技术经常被提起和引用, 它们的使用目的和场景是完全不一样的(至少,它们的操作方式是完全不一样的) | 一刀 翻译于 1年前 0人顶 顶 翻译的不错哦! |
自从我使用Python工作以来,我已经用过了各种各样的.*ython工具了。但是直到最近我才花时间去理解到底它们是干嘛的,它们是怎样工作的,为什么它们是不可或缺的。 在这篇文章里面,我会介绍各种Python的实现,最后以对PyPy的介绍结尾, 因为我个人认为它是Python的未来。 所有的都从理解什么是"Python"开始。 如果你对机器码,虚拟机之类的很熟了,你可以跳过开头,直接从 "即时编译: PyPy和它的未来" 这部分开始看起。 | 一刀 翻译于 1年前 0人顶 顶 翻译的不错哦! |
这是个Python新人都会迷惑的问题。 | 青崖白鹿 翻译于 1年前 0人顶 顶 翻译的不错哦! |
对使用最广泛的实现(CPython:用C实现的,通常简单的说成Python,若你不知道我所说的这些,那很肯能你在使用的就是CPython)而言,这个问题的答案是:解释型,但带有一些编译型特征。CPython把Python源码编译*成字节码,之后再解释这些字节码,执行之。 *注意:这个编译不是通常意义上的编译。通常我们说的编译,是指把高级语言代码转换成机器码。但这里的编译实际上是另一种意义上的编译。(译者,这句话不是很懂,原文是it is a ‘compilation’ of sorts,不知作何解,求教各位读者。) 再详细看下上面的答案吧,这有助于我们理解本文中后面会讲到的几个概念。 | 青崖白鹿 翻译于 1年前 1人顶 顶 翻译的不错哦! |
了解字节码和机器码(或者native code)的区别是很重要的,最好的办法或许是看看例子: | 青崖白鹿 翻译于 1年前 1人顶 顶 翻译的不错哦! |
机器码随机器的变化而变化,但字节码在所有的机器上都是一样的。有人可能会认为机器码是对特定环境优化了的。 回到CPython,工具链的执行过程如下: CPython编译你的Python源代码,生成字节码。 字节码随后在CPython虚拟机上执行。 初学者常常因为看到.pyc文件而假设Python是编译型的。这也有一些合理性:.pyc文件正式之后要解释的字节码文件。所以,你若之前运行过你的Python代码,生成了.pyc文件,再次运行时就要快得多,因为不需要再次编译生成字节码了。 | 青崖白鹿 翻译于 1年前 0人顶 顶 翻译的不错哦! |
正如我之前所述,Python有很多实现。前面也提到,CPython是最通用的。这是一个用C实现的,被认为是”默认“的实现。 | 青崖白鹿 翻译于 1年前 0人顶 顶 翻译的不错哦! |
CPython中很容易为你的Python代码写C扩展,因为最终都是由C解释器执行的。另一方面,Jython则使得和其他java程序共同工作很容易:无需其他工作,你就可导入任何Java类,在你的Jython程序中使用其他Java类。(题外话,若你没有认真思考,这一段会很难。此时我们已经在讨论把不同语言的代码混在一起,并编译成同一程序。(Rostin 提出混合Fortran和C代码编程已经有一段时间了。所以,这并不新鲜,但仍然很酷。)) 下面是一个例子,一段合法的Jython代码: ? Language Runtime (CLR),同JVM相对应。 | 青崖白鹿 翻译于 1年前 0人顶 顶 翻译的不错哦! |
你可能会说,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字符串了。 | 一刀 翻译于 1年前 0人顶 顶 翻译的不错哦! |
我们已经有了一个使用C写的Python实现,一个用Java写的,一个用C#写的。接下来就是:用Python写的Python实现(有心人可能会注意这句话有点问题,是个死循环,^_^) | 一刀 翻译于 1年前 0人顶 顶 翻译的不错哦! |
例如, 被JIT(及时编译)采用的通用方法: 标识被经常执行的字节码。 把其编译成本地的机器码。 缓存该结果。 当同样的的字节码再次被执行的时候,会取预编译的机器码,得到好处(例如速度提升)。 这是关于PyPy的用处: 把JIT代入Python语言 (参看前面成果的附录).当然也有其他目的: PyPy 目标是成为一个跨平台,轻内存,支持stackless(译注:stackless为python提供微线程扩展,具有并发特性)。 但是及时编译才是它真正的卖点。 基于一系列时间测试的平均, 据说性能上能提高6.27倍. 停一下, 看看下面这个由PyPy Speed Center提供的图表: | 嘉陵江的小鱼 翻译于 1年前 0人顶 顶 翻译的不错哦! |
PyPy具有巨大的潜力,在这一点上,它与CPython高度兼容所以它能运行Flask,Django等等)。 |
但使得内存管理和优化大大的容易。
一个编译RPython代码为了各种目标和加入及时编译的编译器。 默认平台是C,也就是从RPython到C编译器,但你也可以瞄准JVM或者其他。
只为清晰,我将引用这些PyPy(1)和PyPy(2)。
嘉陵江的小鱼
翻译于 1年前
0人顶
顶 翻译的不错哦!
为什么你在同一层面下同时需要这两者? 你可以这样想一下:PyPy(1)是一个用RPython写的解释器,因此它能加载用户的Python代码并将它编译成字节码。但是这个用RPython写的解释器本身要能运行,就必须要被另外一个Python实现去解释,对不? 我们可以直接用CPython去运行这个解释器。但是这个还不够快 取而代之,我们使用了PyPy(2)(参考 RPython的工具链)去编译这个PyPy的解释器,生成其他平台(比如C, JVM或CLI)代码在我们的机器上运行,并且还加入了JIT特性。这个很神奇:PyPy动态的将JIT加入一个解释器,生成它自己编译器!(这就是核心原理:我们在编译一个解释器,并同时加入了另外一个单独的编译器到里面去)。 | 一刀 翻译于 1年前 0人顶 顶 翻译的不错哦! |
最终结果就是一个融合了JIT优化特性的单独的可执行文件,用来解释执行我们的Python源代码。这就是我们之前想要达到的效果。这么讲可能比较拗口,下面这张图可能会解释的比较清楚点: 再次重申下,PyPy真正可贵之处在于我们可以利用RPython实现各种不同的Python解释器,不用去关心JIT(除了一些小的提示外)。PyPy到时候会利用RPython工具链/PyPy(2)为我们自动实现JIT | 一刀 翻译于 1年前 0人顶 顶 翻译的不错哦! |
事实上,我们还可以更抽象一点,我们理论上可以写一个适用于任何语言的解释器,然后将它扔给PyPy,最后获得那种语言的JIT。原因是PyPy仅仅关心的是优化解释器,而不会去关心这个解释器到底解释的是什么语言。 理论上你自己可以写一个适用于任何语言的解释器,然后将这个解释器传给PyPy,最后你得到这个语言的一个JIT。一个简单的题外话,我这里想提一下,JIT本事是相当棒的。它使用了一种叫做跟踪的技术,按照下面的步骤执行: 执行解释器并解释执行所有代码(还没有加入JIT特性) 对被解释过的代码做一些记录 确认你已经执行过的操作 将确认过的这些代码编译成本地机器码 想获取更多信息,可以参考这篇文章,易于理解,并且非常有趣 最后收尾:我们使用PyPy的RPython-to-C(或者其他目标平台)编译器去编译PyPy的基于RPython实现的解释器。 | 一刀 翻译于 1年前 0人顶 顶 翻译的不错哦! |
为什么它如此的伟大?为什么这个疯狂的想法值得我们去追求?我想Alex Gaynor已经在他的博客上面做了很好的解释了:“[PyPy就是未来] 因为[它]提供了更快的速度,更大的灵活性,并且对于Python的成长也提供了一个更好的平台” | 一刀 翻译于 1年前 0人顶 顶 翻译的不错哦! |
Python 3000 (Py3k): Python 3.0的一个别名,2008年释出的一个主要版本,但是它并不向后兼容.。Py3k团队预测这个版本被完全采用可能需要5年时间.。现在绝大多数(注意:这个是江湖传闻)Python开发者继续在使用2.x版本,不过现在人们越来越多的对Py3k开始关心了。 | 一刀 翻译于 1年前 0人顶 顶 翻译的不错哦! |
其它翻译版本(1) |
RubyPython: Ruby和Python虚拟机的一座桥梁。允许你在你的Ruby代码中嵌入Python代码。你定义Python的起始位置,然后RubyPython负责在不同VM直接传递整理数据。 |
相关文章推荐
- 为什么有这么多 Python?Python是解释型的还是编译型的?
- 为什么有这么多 Python?
- 为什么这么多Python框架
- 为什么有这么多 Python?Python是解释型的还是编译型的?
- 为什么有这么多 Python版本
- 为什么这么多人开始学Python?看完这些你就清楚了
- 为什么有这么多 Python?
- 为什么会有这么多Python
- 为什么这么多人喜欢“空中危机”
- 学这么多技术是为什么
- 为什么中国的钱这么多
- IE有这么多问题,为什么用的人这么多
- 模板之小试牛刀---我有点明白为什么这么多人骂c++了(补,补充一些骂点)
- 婚姻有这么多陷阱,为什么人要结婚?(转)
- Python为什么不需要swap(a, b)
- Python为什么不需要swap(a, b)
- 模板之小试牛刀---我有点明白为什么这么多人骂c++了
- 为什么国内这么多模仿的案例?
- 为什么http://msdn2.microsoft.com/zh-cn/default.aspx 这么多ViewState
- 为什么我比别人差这么多?