若是解释Python,什么是.pyc文件?

我已经了解Python是一种解释型语言......可是,当我查看个人Python源代码时,我看到.pyc文件,Windows将其识别为“编译的Python文件”。 这些来自哪里? 后端


#1楼

Python代码经历了两个阶段。 第一步将代码编译成.pyc文件,这其实是一个字节码。 而后使用CPython解释器解释此.pyc文件(字节码)。 请参阅连接。 这里用简单的术语解释代码编译和执行的过程。 缓存


#2楼

它们包含字节代码 ,这是Python解释器编译源的代码。 而后,此代码由Python的虚拟机执行。 字体

Python的文档解释了这样的定义: 优化

Python是一种解释型语言,与已编译的语言相反,尽管因为字节码编译器的存在,区别可能很模糊。 这意味着能够直接运行源文件,而无需显式建立随后运行的可执行文件。 spa


#3楼

这些是由Python解释器在导入.py文件时建立的,它们包含导入的模块/程序的“编译字节码”,其思想是从源代码到字节码的“转换”(只须要完成)若是.pyc比相应的.py文件更新,则能够在后续import跳过一次,从而加快启动速度。 但它仍然被解释。 翻译


#4楼

我已经理解Python是一种解释语言...... 指针

这种流行的模因是不正确的,或者更确切地说,是基于对(天然)语言水平的误解而构建的:相似的错误就是说“圣经是精装书”。 让我解释一下比喻...... code

“圣经”是“一本书”,意思是成为一 (实际的,物理对象)书籍; 被肯定为“圣经副本”的书籍应该具备一些基本的共同点(内容,即便是那些可使用不一样语言,具备不一样的可接受翻译,脚注和其余注释的水平) - 然而,这些书籍是很好地容许在被认为是基本的无数方面有所区别 - 绑定的种类,绑定的颜色,打印中使用的字体,插图(若是有的话),宽的可写边距,内置书签的数量和种类, 等等等等。 对象

颇有可能的是,圣经的典型印刷确实是精装书 - 毕竟,它是一本一般意味着一遍又一遍地阅读的书,在几个地方加书签,翻阅寻找给定的章节和诗句指针等等,一个好的精装书绑定可使给定的副本在这种使用下持续更长时间。 然而,这些是平凡的(实际的)问题,不能用于肯定给定的实际书籍对象是不是圣经的副本:平装印刷是彻底可能的! 内存

相似地,Python是定义一类语言实现的 “语言”,它必须在某些基本方面都是类似的(语法,大多数语义,除了那些明确容许它们不一样的那些部分)但彻底容许几乎每一个“实现”细节都有所不一样 - 包括他们如何处理他们给出的源文件,他们是否将源代码编译成某种较低级别的形式(若是是,那么哪一种形式 - 以及他们是否保存这些形式编译表格,磁盘或其余地方),他们如何执行所述表格,等等。

经典实现CPython一般简称为“Python” - 但它只是几个生产质量实现中的一个,与Microsoft的IronPython(编译为CLR代码,即“.NET”)并列,Jython (编译为JVM代码),PyPy(用Python自己编写,能够编译成各类各样的“后端”形式,包括“即时”生成的机器语言)。 它们都是Python(==“Python语言的实现”),就像许多表面上不一样的书籍对象均可以是圣经(==“圣经的副本”)。

若是你对CPython特别感兴趣:它将源文件编译成特定于Python的低级表单(称为“字节码”),在须要时自动执行(当没有与源文件对应的字节码文件时,或者字节码文件比源文件旧,或由不一样的Python版本编译),一般将字节码文件保存到磁盘(以免未来从新编译它们)。 OTOH IronPython一般会编译为CLR代码(将它们保存到磁盘或不依赖)和Jython保存到JVM代码(将它们保存到磁盘或不保存 - 若是保存它们将使用.class扩展名)。

而后,这些较低级别的表单由适当的“虚拟机”(也称为“解释器”)执行 - CPython VM,.Net运行时,Java VM(也称为JVM)。

所以,从这个意义上来讲(典型的实现是作什么的),当且仅当C#和Java是:全部这些都具备首先生成字节码的典型实现策略,而后经过VM /解释器执行它时,Python是一种“解释语言” 。

更有可能的焦点是编译过程的“重”,慢和高仪式。 CPython旨在尽量快地编译,尽量轻量级,尽量少的仪式 - 编译器执行很是少的错误检查和优化,所以它能够快速运行而且在少许内存中运行,这样就能够了能够在须要时自动且透明地运行,而无需用户甚至须要知道正在进行编译,大多数状况下。 Java和C#一般在编译期间接受更多工做(所以不执行自动编译),以便更完全地检查错误并执行更多优化。 它是灰度级的连续体,而不是黑色或白色的状况,而且将阈值置于某个给定的水平而且仅在该级别之上将其称为“编译”将是彻底随意的! - )


#5楼

Python(至少是它最多见的实现)遵循将原始源代码编译为字节代码,而后解释虚拟机上的字节代码的模式。 这意味着(一样,最多见的实现)既不是纯解释器也不是纯编译器。

然而,另外一方面,编译过程大可能是隐藏的 - .pyc文件基本上被视为缓存; 他们加快了速度,但你一般根本不须要了解它们。 它会根据文件时间/日期戳自动使其无效并从新加载(从新编译源代码)。

大约在我看到这个问题的惟一一次是当编译的字节码文件以某种方式在将来很好地得到时间戳时,这意味着它老是看起来比源文件更新。 因为它看起来更新,源文件从未被从新编译,因此不管你作了什么改变,它们都会被忽略......

相关文章
相关标签/搜索