如果解释Python，.pyc文件是什么？

Question

Python 是一种解释型语言。但为什么我的源目录包含 .pyc 文件，Windows 将其识别为“已编译的 Python 文件”？

原文由 froadie 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

它们包含 字节码，这是 Python 解释器将源代码编译成的内容。然后这段代码由 Python 的虚拟机执行。

Python 的文档 是这样解释定义的：

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

原文由 unwind 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 2

我被告知 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），视情况而定。

因此，从这个意义上说（典型的实现是做什么的），Python 是一种“解释型语言”当且仅当 C# 和 Java 是：它们都有一个典型的实现策略，即首先生成字节码，然后通过 VM/解释器执行它.

更有可能的是，重点是编译过程的“繁重”、“缓慢”和“繁重”。 CPython 被设计为尽可能快地编译，尽可能轻量级，尽可能少的仪式——编译器做很少的错误检查和优化，所以它可以快速运行并且占用少量内存，这反过来又允许它在需要时自动透明地运行，大多数时候用户甚至不需要知道正在进行编译。 Java 和 C# 通常在编译期间接受更多工作（因此不执行自动编译），以便更彻底地检查错误并执行更多优化。它是灰度的连续统一体，而不是黑色或白色的情况，将阈值设置在某个给定级别并说只有在该级别以上才称其为“编译”是完全任意的！-)

原文由 Alex Martelli 发布，翻译遵循 CC BY-SA 3.0 许可协议