python解释执行原理

发布时间:2016-12-6 13:55:00 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"python解释执行原理",主要涉及到python解释执行原理方面的内容,对于python解释执行原理感兴趣的同学可以参考一下。

本文转自:http://blog.csdn.net/tjxy_20081/article/details/8937687 谈到了Python语句的两种执行方式,实际上,这两种运行方式在本质 上是相同的,它们都是由解释器来解释执行我们提供的Python语句。 这里所说的解释执行是相对于编译执行而言的。我们知道,使用诸如 C或C++之类的编译性语言编写的程序可以从源文件转换成计算机使用 的机器语言, 经连接器连接后形成二进制可执行文件。当我们运行二进制可执行程 序的时候,因为已经编译好了,所以加载器软件把二进制程序从硬盘 载入内存中并运行。     与之不同,Python语言写的程序不需要编译成二进制代码,它可以直 接从源代码运行程序。当我们运行Python文件程序的时候, Python解释器把源代码转换成中间形式:字节码,然后再由Python虚 拟机来执行这些字节码,如图5所示。 这样的话,我们就用不着担心程序的编译,库的连接加载等问题了, 所有这些工作都由Python虚拟机代劳了。 对于Python的解释语言特性,我们要一分为二的看待。一方面,每次 运行时都要进行转换成 字节码,然后再由虚拟机把字节码转换成机器语言,最后才能在硬件 上运行。较之于编译性 编程 语言,每次运行都会多出两道工序,所以它的性能会受到影响。另一 方面,由于不用关心程 序的编译以及库的连接等问题,所以开发工作会变得更轻松;同时虚 拟机距离物理机器更远 了, 所以Python程序更加易于移植,实际上无需改动就能在多种平台上运 行。     1. 在具体计算机上实现一种语言,首先要确定的是表示该语言语义解释 的虚拟计算机,一个关键的问题是程序执行时的基本表示是实际计算 机上的机器语言还是虚拟机 的机器语言。这个问题决定了语言的实现。根据这个问题的回答,可 以将程序设计语言划分为两大类:编译型语言和解释型语言。   2. 由编译型语言编写的源程序需要经过编译、汇编和链接才能输出目标 代码,然后机器执行目标代码,得出运行结果,目标代码由机器指令 组成,一般不能独立运行, 因为源程序中可能使用了某些汇编程序不能解释引用的库函数,而库 函数代码又不在源程序中,此时还需要链接程序完成外部引用和目标 模块调用的链接任务,最后 输出可执行代码。C、C++、Fortran、Pascal、Ada都是编译实现的。   3. 解释型语言的实现中,翻译器并不产生目标机器代码,而是产生易于 执行的中间代码,这种中间代码与机器代码是不同的,中间代码的解 释是由软件支持的,不能直接 使用硬件,软件解释器通常会导致执行效率较低。用解释型语言编写 的程序是由另一个可以理解中间代码的解释程序执行的。与编译程序 不同的是,解释程序的任务 是逐一将源程序的语句解释成可执行的机器指令,不需要将源程序翻 译成目标代码后再执行。对于解释型Basic语言,需要一个专门的解 释器解释执行 Basic程序,每条语言只有在执行才被翻译。这种解释型语言每执行 一次就翻译一次,因而效率低下。   4. Java很特殊,Java程序也需要编译,但是没有直接编译称为机器语言 ,而是编译称为字节码,然后在Java虚拟机上用解释方式执行字节码 。Python 的也采用了类似Java的编译模式,先将Python程序编译成Python字节 码,然后由一个专门的Python字节码解释器负责解释执行字节码。   (Java虚拟机对字节码的执行相当于模拟一个cpu,而ruby1.8--在虚 拟机还未出现前--是通过解释成语法树执行。)   Python是一个解释型的语言。但是为了效率上的考虑,Python也提供 了编译的方法。编译之后是bytecode的形式。Python也提供了和Java 类似的VM来执行这样的bytecode。不同的是,因为Python是一个解释 型的语言,所以编译(compile)不是一个强制的操作。事实上,编 译是一个自动的过程。多数情况下,你甚至不会在意他的存在。编译 成bytecode可以节省加载模块的时间,从而提高效率   除了效率原因,bytecode也增加了反向工程的难度,在某种程度上保 护你的代码。当然,反编译仍然是可以的。所以如果真的想保护代码 ,还是用别的方法吧。 另外Python还提供了-O选项,可以编译生成“优化”的bytecode,文 件扩展名是.pyo。但实际上优化的内容有限,作用不大。 如果希望生成可执行文件,就要依赖于第三方的工具了。   ------------------------------------------------------------------------------------------------------------ 1. Python是一门解释型语言? 我初学Python时,听到的关于Python的第一句话就是,Python是一门解释性语言,我就这样一直相信下去,直到发现了*.pyc文件的存在。如果是解释型语言,那么生成的*.pyc文件是什么呢?c应该是compiled的缩写才对啊! 为了防止其他学习Python的人也被这句话误解,那么我们就在文中来澄清下这个问题,并且把一些基础概念给理清。 2. 解释型语言和编译型语言 计算机是不能够识别高级语言的,所以当我们运行一个高级语言程序的时候,就需要一个“翻译机”来从事把高级语言转变成计算机能读懂的机器语言的过程。这个过程分成两类,第一种是编译,第二种是解释。 编译型语言在程序执行之前,先会通过编译器对程序执行一个编译的过程,把程序转变成机器语言。运行时就不需要翻译,而直接执行就可以了。最典型的例子就是C语言。 解释型语言就没有这个编译的过程,而是在程序运行的时候,通过解释器对程序逐行作出解释,然后直接运行,最典型的例子是Ruby。 通过以上的例子,我们可以来总结一下解释型语言和编译型语言的优缺点,因为编译型语言在程序运行之前就已经对程序做出了“翻译”,所以在运行时就少掉了“翻译”的过程,所以效率比较高。但是我们也不能一概而论,一些解释型语言也可以通过解释器的优化来在对程序做出翻译时对整个程序做出优化,从而在效率上超过编译型语言。 此外,随着Java等基于虚拟机的语言的兴起,我们又不能把语言纯粹地分成解释型和编译型这两种。 用Java来举例,Java首先是通过编译器编译成字节码文件,然后在运行时通过解释器给解释成机器文件。所以我们说Java是一种先编译后解释的语言。 再换成C#,C#首先是通过编译器将C#文件编译成IL文件,然后在通过CLR将IL文件编译成机器文件。所以我们说C#是一门纯编译语言,但是C#是一门需要二次编译的语言。同理也可等效运用到基于.NET平台上的其他语言。 3. Python到底是什么 其实Python和Java/C#一样,也是一门基于虚拟机的语言,我们先来从表面上简单地了解一下Python程序的运行过程吧。 当我们在命令行中输入python hello.py时,其实是激活了Python的“解释器”,告诉“解释器”:你要开始工作了。可是在“解释”之前,其实执行的第一项工作和Java一样,是编译。 熟悉Java的同学可以想一下我们在命令行中如何执行一个Java的程序: javac hello.java java hello 只是我们在用Eclipse之类的IDE时,将这两部给融合成了一部而已。其实Python也一样,当我们执行python hello.py时,他也一样执行了这么一个过程,所以我们应该这样来描述Python,Python是一门先编译后解释的语言。 4. 简述Python的运行过程 在说这个问题之前,我们先来说两个概念,PyCodeObject和pyc文件。 我们在硬盘上看到的pyc自然不必多说,而其实PyCodeObject则是Python编译器真正编译成的结果。我们先简单知道就可以了,继续向下看。 当python程序运行时,编译的结果则是保存在位于内存中的PyCodeObject中,当Python程序运行结束时,Python解释器则将PyCodeObject写回到pyc文件中。 当python程序第二次运行时,首先程序会在硬盘中寻找pyc文件,如果找到,则直接载入,否则就重复上面的过程。 所以我们应该这样来定位PyCodeObject和pyc文件,我们说pyc文件其实是PyCodeObject的一种持久化保存方式。 5. 运行一段Python程序 我们来写一段程序实际运行一下: 程序本身毫无意义。我们继续看: 然而我们在程序中并没有看到pyc文件,仍然是test.py孤零零地呆在那! 那么我们换一种写法,我们把print_str方法换到另外的一个python模块中: 然后运行程序: 这个时候pyc文件出现了,其实认真思考一下不难得到原因,我们考虑一下实际的业务情况。 6. pyc的目的是重用 回想本文的第二段在解释编译型语言和解释型语言的优缺点时,我说编译型语言的优点在于,我们可以在程序运行时不用解释,而直接利用已经“翻译”过的文件。也就是说,我们之所以要把py文件编译成pyc文件,最大的优点在于我们在运行程序时,不需要重新对该模块进行重新的解释。 所以,我们需要编译成pyc文件的应该是那些可以重用的模块,这于我们在设计软件类时是一样的目的。所以Python的解释器认为:只有import进来的模块,才是需要被重用的模块。 这个时候也许有人会说,不对啊!你的这个问题没有被解释通啊,我的test.py不是也需要运行么,虽然不是一个模块,但是以后我每次运行也可以节省时间啊! OK,我们从实际情况出发,思考下我们在什么时候才可能运行python xxx.py文件: A. 执行测试时。 B. 开启一个Web进程时。 C. 执行一个程序脚本。 我们逐个来说,第一种情况我们就不用多说了,这个时候哪怕所有的文件都没有pyc文件都是无所谓的。 第二种情况,我们试想一个webpy的程序把,我们通常这样执行: 抑或者: 然后这个程序就类似于一个守护进程一样一直监视着8181/9002端口,而一旦中断,只可能是程序被杀死,或者其他的意外情况,那么你需要恢复要做的是把整个的Web服务重启。那么既然一直监视着,把PyCodeObject一直放在内存中就足够了,完全没必要持久化到硬盘上。 最后一个情况,执行一个程序脚本,一个程序的主入口其实很类似于Web程序中的Controller,也就是说,他负责的应该是Model之间的调度,而不包含任何的主逻辑在内,如我在http://www.cnblogs.com/kym/archive/2010/07/19/1780407.html中所提到,Controller应该就是一个Facade,无任何的细节逻辑,只是把参数转来转去而已,那么如果做算法的同学可以知道,在一段算法脚本中,最容易改变的就是算法的各个参数,那么这个时候给持久化成pyc文件就未免有些画蛇添足了。 所以我们可以这样理解Python解释器的意图,Python解释器只把我们可能重用到的模块持久化成pyc文件。 7. pyc的过期时间 说完了pyc文件,可能有人会想到,每次Python的解释器都把模块给持久化成了pyc文件,那么当我的模块发生了改变的时候,是不是都要手动地把以前的pyc文件remove掉呢? 当然Python的设计者是不会犯这么白痴的错误的。而这个过程其实就取决于PyCodeObject是如何写入pyc文件中的。 我们来看一下import过程的源码吧: 这段代码比较长,我们只来看我标注了的代码,其实他在写入pyc文件的时候,写了一个Long型变量,变量的内容则是文件的最近修改日期,同理,我们再看下载入pyc的代码: 不用仔细看代码,我们可以很清楚地看到原理,其实每次在载入之前都会先检查一下py文件和pyc文件保存的最后修改日期,如果不一致则重新生成一份pyc文件。 8. 写在最后的 其实了解Python程序的执行过程对于大部分程序员,包括Python程序员来说意义都是不大的,那么真正有意义的是,我们可以从Python的解释器的做法上学到什么,我认为有这样的几点: A. 其实Python是否保存成pyc文件和我们在设计缓存系统时是一样的,我们可以仔细想想,到底什么是值得扔在缓存里的,什么是不值得扔在缓存里的。 B. 在跑一个耗时的Python脚本时,我们如何能够稍微压榨一些程序的运行时间,就是将模块从主模块分开。(虽然往往这都不是瓶颈) C. 在设计一个软件系统时,重用和非重用的东西是不是也应该分开来对待,这是软件设计原则的重要部分。 D. 在设计缓存系统(或者其他系统)时,我们如何来避免程序的过期,其实Python的解释器也为我们提供了一个特别常见而且有效的解决方案。  

上一篇:作业
下一篇:CentOS之Xen操作

相关文章

相关评论