引用来自:here
解释型语言和编译型
编译型
解释型
Python是解释型的还是编译型的?
这是个Python新人都会迷惑的问题。
首先需要明了的是Python只是一个接口。有一个关于Python应该做什么以及怎么做的具体说明(就像其他任何接口一样 ),并且对应的有很多具体的实现(也像其他接口一样)。
其次需要知道的是“解释型”和“编译型”是具体实现的特性,而不是接口的特性。
所以,这个问题本身就没有组织好。
Python是解释型还是编译型的?这个问题真的没有组织好。
对使用最广泛的实现(CPython:用C实现的,通常简单的说成Python,若你不知道我所说的这些,那很肯能你在使用的就是CPython)而言,这个问题的答案是:解释型,但带有一些编译型特征。CPython把Python源码编译*成字节码,之后再解释这些字节码,执行之。
*注意:这个编译不是通常意义上的编译。通常我们说的编译,是指把高级语言代码转换成机器码。但这里的编译实际上是另一种意义上的编译。(译者,这句话不是很懂,原文是it is a ‘compilation’ of sorts,不知作何解,求教各位读者。)
再详细看下上面的答案吧,这有助于我们理解本文中后面会讲到的几个概念。
字节码 vs. 机器码
了解字节码和机器码(或者native code)的区别是很重要的,最好的办法或许是看看例子:
简而言之:机器码快的多,但字节码更易迁移,也更安全。 |
机器码随机器的变化而变化,但字节码在所有的机器上都是一样的。有人可能会认为机器码是对特定环境优化了的。
字节码随后在CPython虚拟机上执行。 初学者常常因为看到.pyc文件而假设Python是编译型的。这也有一些合理性:.pyc文件正式之后要解释的字节码文件。所以,你若之前运行过你的Python代码,生成了.pyc文件,再次运行时就要快得多,因为不需要再次编译生成字节码了。
|
可选的虚拟机:Jython,IronPython等正如我之前所述,Python有很多实现。前面也提到,CPython是最通用的。这是一个用C实现的,被认为是”默认“的实现。 但其他的呢?其中最显赫的之一就是Jython,一个用Java实现的采用了JVM的实现。CPython生成在CPython虚拟机上运行的字节码,而Jython生成在JVM上运行的java字节码(这同编译Java程序生成java字节码的过程是一样的)。 ”为啥你要用其他的实现?”,你可能会如此发问。好吧,对开发者而言,不同的实现对不同的技术难题的支持程度不一样。 |
CPython中很容易为你的Python代码写C扩展,因为最终都是由C解释器执行的。另一方面,Jython则使得和其他java程序共同工作很容易:无需其他工作,你就可导入任何Java类,在你的Jython程序中使用其他Java类。(题外话,若你没有认真思考,这一段会很难。此时我们已经在讨论把不同语言的代码混在一起,并编译成同一程序。(Rostin 提出混合Fortran和C代码编程已经有一段时间了。所以,这并不新鲜,但仍然很酷。)) 下面是一个例子,一段合法的Jython代码:
|
你可能会说,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字符串了。 |