> That's my point. It's a misnomer.

I disagree (as do the books sitting on my shelf), but I'm not really interested in debating this point of terminology.

> Well, not so much as you'd think.

No, really there is. Trying to deny this isn't insightful, it's myopic. Take the C function:

  int plus2(int x) { return x + 2; }

You can directly compile this into the following machine code, which needs no supporting runtime:

  lea    eax,[rdi+0x2]
  ret

Now take the equivalent function in Python:

  def plus2(x):
    return x + 2

Yes, it's true that this "compiles" (internally) to the following byte-code:

  3           0 LOAD_FAST                0 (x)
              3 LOAD_CONST               1 (2)
              6 BINARY_ADD          
              7 RETURN_VALUE

The question is: can you execute this byte-code without implementing an entire Python interpreter? The answer is no, because the BINARY_ADD opcode has to handle the case where "x" is an object that implements an overloaded operator __add__(). In this case, the user's __add__() method can be arbitrary Python code, and therefore requires an entire Python interpreter to fully and generally execute.

I expect you will want to talk about the limited circumstances where you can specialize this function ahead-of-time, thereby avoiding the fully-general implementation. This would again be missing the point. Python and C are different beasts, and this difference has far-reaching consequences on their implementations. Trying to draw an equivalence between all "compiled languages" does a disservice to people who are trying to understand the differences between them.