python – 如果解析Python,那么什么是.pyc文件?

我已经了解Python是一种解释型语言……但是,当我查看我的Python源代码时,我看到的.pyc是Windows文件,其中Windows标识为“编译的Python文件”。这些来自哪里?


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

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

Python是一种解释型语言,与编译语言相反,但由于字节码编译器的存在,区别可能很模糊。这意味着可以直接运行源文件,而无需显式创建随后运行的可执行文件。


我已经理解Python是一种解释语言……

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

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

很有可能的是,圣经的典型印刷确实是精装书 – 毕竟,它是一本通常意味着一遍又一遍地阅读的书,在几个地方都有书签,通过寻找给定的章节和诗句来翻阅等等,一个好的精装书绑定可以使给定的副本在这种使用下持续更长时间。然而,这些是平凡的(实际的)问题,不能用于确定给定的实际书籍对象是否是圣经的副本:平装印刷是完全可能的!

类似地,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#通常在编译期间接受更多工作(因此不执行自动编译),以便更彻底地检查错误并执行更多优化。它是灰度的连续体,而不是黑色或白色的情况,

添加评论

友情链接:蝴蝶教程