我已经明白了
Python 是一种解释型语言...
这种流行的模因是不正确的，或者更确切地说，是建立在对（自然）语言水平的误解之上的：类似的错误是说“圣经是一本精装书”。让我解释一下这个比喻...
“圣经”是“一本书”，意思是它是一本书class（实际的、被识别为书籍的物理对象）；被认定为“圣经副本”的书籍应该有一些基本的共同点（内容，尽管这些书籍可能采用不同的语言，具有不同的可接受的翻译、脚注和其他注释的级别）——然而，这些书是完全允许在许多方面有所不同not被认为是基本的——装订类型、装订颜色、印刷中使用的字体、插图（如果有）、可写边距是否宽、内置书签的数量和类型等等。
很有可能typical圣经的印刷确实会采用精装本——毕竟，这是一本通常需要一遍又一遍地阅读的书，在几个地方加了书签，翻阅寻找给定的章节和诗句指针，等等，等等，良好的精装装订可以使给定的副本在这种使用下保存更长时间。然而，这些都是平凡（实际）的问题，不能用来确定给定的实际书籍对象是否是圣经的副本：平装本印刷是完全可能的！
类似地，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# 通常在编译期间接受更多工作（因此不执行自动编译），以便更彻底地检查错误并执行更多优化。这是灰度的连续体，而不是黑色或白色的情况，并且在某个给定级别设置阈值并说只有高于该级别才将其称为“编译”是完全任意的！-）
