CPU实际上只能理解机器代码。对于解释型程序，解释器的最终目标是将程序代码“解释”为机器代码。然而，现代解释语言通常不会直接解释人类代码，因为它效率太低。

Python解释器首先读取人类代码，并在将其解释为机器代码之前将其优化为一些中间代码。这就是为什么你总是需要另一个程序来运行Python脚本，不像在c++中，你可以直接运行编译后的可执行代码。例如，c:\Python27\python.exe或/usr/bin/python.

CPU实际上只能理解机器代码。对于解释型程序，解释器的最终目标是将程序代码“解释”为机器代码。然而，现代解释语言通常不会直接解释人类代码，因为它效率太低。

Python解释器首先读取人类代码，并在将其解释为机器代码之前将其优化为一些中间代码。这就是为什么你总是需要另一个程序来运行Python脚本，不像在c++中，你可以直接运行编译后的可执行代码。例如，c:\Python27\python.exe或/usr/bin/python.

First off, interpreted/compiled is not a property of the language but a property of the implementation. For most languages, most if not all implementations fall in one category, so one might save a few words saying the language is interpreted/compiled too, but it's still an important distinction, both because it aids understanding and because there are quite a few languages with usable implementations of both kinds (mostly in the realm of functional languages, see Haskell and ML). In addition, there are C interpreters and projects that attempt to compile a subset of Python to C or C++ code (and subsequently to machine code).

Second, compilation is not restricted to ahead-of-time compilation to native machine code. A compiler is, more generally, a program that converts a program in one programming language into a program in another programming language (arguably, you can even have a compiler with the same input and output language if significant transformations are applied). And JIT compilers compile to native machine code at runtime, which can give speed very close to or even better than ahead of time compilation (depending on the benchmark and the quality of the implementations compared).

But to stop nitpicking and answer the question you meant to ask: Practically (read: using a somewhat popular and mature implementation), Python is compiled. Not compiled to machine code ahead of time (i.e. "compiled" by the restricted and wrong, but alas common definition), "only" compiled to bytecode, but it's still compilation with at least some of the benefits. For example, the statement a = b.c() is compiled to a byte stream which, when "disassembled", looks somewhat like load 0 (b); load_str 'c'; get_attr; call_function 0; store 1 (a). This is a simplification, it's actually less readable and a bit more low-level - you can experiment with the standard library dis module and see what the real deal looks like. Interpreting this is faster than interpreting from a higher-level representation.

字节码要么被解释(请注意，在理论和实际性能上，直接解释和首先编译为一些中间表示并解释它之间存在差异)，就像参考实现(CPython)一样，要么在运行时被解释并编译为优化的机器代码，就像PyPy一样。

是的，它既是编译语言也是解释语言。那为什么我们一般称它为解释语言呢?

看到它是如何编译和解释的了吗?

首先我想说的是，如果你来自Java世界，你会更喜欢我的回答。

在Java中，源代码首先通过javac编译器转换为字节码，然后定向到JVM(负责生成用于执行的本机代码)。现在我想向你展示，我们将Java称为编译语言，因为我们可以看到它确实编译源代码，并通过以下方式提供.class文件(除了字节码之外什么都没有):

javac Hello.java ------->生成Hello.class文件

java Hello -------->将字节码定向到JVM执行

同样的事情也发生在python中，即首先通过编译器将源代码转换为字节码，然后定向到PVM(负责生成用于执行的本机代码)。现在我想向你们展示，我们通常称Python为解释语言，因为编译是在幕后进行的 当我们运行python代码时:

python Hello.py ------->直接执行代码，如果代码语法正确，我们可以看到输出

@ python Hello.py看起来像是直接执行，但实际上它首先生成由解释器解释的字节码，以产生用于执行目的的本机代码。

CPython-承担编译和解释的责任。

如果你需要更多的细节，看看下面的几行:

正如我提到的，CPython编译源代码，但实际的编译是在cython的帮助下进行的，然后在CPython的帮助下进行解释

现在让我们稍微讨论一下即时编译器在Java和Python中的作用

在JVM中存在Java解释器，它逐行解释字节码以获得用于执行的本机机器码，但当Java字节码由解释器执行时，执行将总是较慢。那么解决方案是什么呢?解决方案是即时编译器，它产生的本机代码可以执行得比解释快得多。一些JVM供应商使用Java解释器，一些使用即时编译器。参考资料:按此处

在python中，要绕过解释器来实现快速执行，请使用另一个python实现(PyPy)而不是CPython。 点击这里查看python的其他实现，包括PyPy。

这真的取决于所使用的语言的实现!不过，在任何实现中都有一个常见的步骤:您的代码首先被编译(翻译)为中间代码——介于您的代码和机器(二进制)代码之间的东西——称为字节码(存储在.pyc文件中)。注意，这是一个一次性步骤，除非修改代码，否则不会重复。

这个字节码在每次运行程序时都会被执行。怎么做?当我们运行程序时，这个字节码(在.pyc文件中)作为输入传递给虚拟机(VM)1——允许我们的程序被执行的运行时引擎——由虚拟机执行。

根据语言实现，VM将解释字节码(在CPython2实现的情况下)或JIT-compile3字节码(在PyPy4实现的情况下)。

注:

计算机系统的模拟

2字节码解释器;该语言的参考实现，用C和Python编写，使用最广泛

在程序执行期间(在运行时)进行的3个编译

4字节码JIT编译器;CPython的替代实现，用RPython (Restricted Python)编写——通常比CPython运行得更快

如果(你懂Java) { Python代码像java一样被转换成字节码。 每次您尝试访问该字节码时，都会再次执行它。 }其他{ Python代码最初被翻译成一种叫做字节码的东西 接近机器语言，但不是真正的机器代码 因此，每次我们访问或运行它时，字节码都会再次执行 ｝