我已经了解Python是一种解释型语言......但是，当我查看我的Python源代码时，我看到.pyc文件，Windows将其识别为“编译的Python文件”。 这些来自哪里？
#1楼
Python代码经历了两个阶段。 第一步将代码编译成.pyc文件，这实际上是一个字节码。 然后使用CPython解释器解释此.pyc文件（字节码）。 请参阅此链接。 这里用简单的术语解释代码编译和执行的过程。
#2楼
它们包含字节代码 ，这是Python解释器编译源的代码。 然后，此代码由Python的虚拟机执行。
Python的文档解释了这样的定义：
Python是一种解释型语言，与已编译的语言相反，尽管由于字节码编译器的存在，区别可能很模糊。 这意味着可以直接运行源文件，而无需显式创建随后运行的可执行文件。
#3楼
这些是由Python解释器在导入.py文件时创建的，它们包含导入的模块/程序的“编译字节码”，其思想是从源代码到字节码的“转换”（只需要完成）如果.pyc比相应的.py文件更新，则可以在后续import跳过一次，从而加快启动速度。 但它仍然被解释。
#4楼
我已经理解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＃通常在编译期间接受更多工作（因此不执行自动编译），以便更彻底地检查错误并执行更多优化。 它是灰度级的连续体，而不是黑色或白色的情况，并且将阈值置于某个给定的水平并且仅在该级别之上将其称为“编译”将是完全随意的！ - ）
#5楼
Python（至少是它最常见的实现）遵循将原始源代码编译为字节代码，然后解释虚拟机上的字节代码的模式。 这意味着（同样，最常见的实现）既不是纯解释器也不是纯编译器。
然而，另一方面，编译过程大多是隐藏的 - .pyc文件基本上被视为缓存; 他们加快了速度，但你通常根本不需要了解它们。 它会根据文件时间/日期戳自动使其无效并重新加载（重新编译源代码）。
大约在我看到这个问题的唯一一次是当编译的字节码文件以某种方式在未来很好地获得时间戳时，这意味着它总是看起来比源文件更新。 由于它看起来更新，源文件从未被重新编译，所以无论你做了什么改变，它们都会被忽略......