I read that some constructs of Python are more efficient because they are compiled in C.

That's not true.

First off, there is nothing in the specification of the Python language that requires that certain functions have to be implemented in a certain language. A Python implementor can choose to implement any function and language construct anyway he wants. For example, in Jython, those functions are implemented in Java, not in C. In IronPython, they are implemented in C#. In PyPy, they might be implemented in RPython or just in Python. In Pynie, they are probably implemented in Python.

Seondly, there is nothing in the specification of the C language that says that it must be compiled. There are interpreters for C.

Thirdly, just because it is in C doesn't mean it's fast. There are C compilers out there which produce really terrible code, and there are pretty fast Python implementations.

And fourth, even if the function implemented in C is blazingly fast, that doesn't necessarily translate into faster execution speed of the overall program. Optimizations typically don't work across languages. For example, the optimizer can't inline the call to map into your program, because your program is written in Python but map is written in C. But inlining is pretty much the foundation of all optimizations, because inlining (and loop unrolling) give nice long straight paths of code without branches or calls, which is what optimizers love.

It's generally interpreted,

Actually, all currently existing Python implementations always compile Python code, they never interpret it.

Why not just compile the whole thing?

That's a good question! Writing everything in the same language has many advantages, some of which I outlined above. (Another one is that it's easier to find collaborators who know one language than two.)

If everything is written in the same language, then performance improvements to that language get multiplied throughout the whole system. If everything is written in C, then making the Python 10 times faster isn't going to speed up your program much, because most of the code isn't Python. Sure, the code you wrote is running 10 times faster, but that code mostly consists of calls to C functions which have the same speed as before.

But if everything is written in Python, then making Python faster will have a ripple effect: the primitive types get faster, the datastructures built on top of those primitive types get faster, the algorithms using those datastructures get faster, the modules using those algorithms get faster and so on.

If the C variant needs x hours less, then I'd invest that time in letting the algorithms run longer/again

"invest" isn't the right word here.

1. Build a working implementation in Python. You'll finish this long before you'd finish a C version.

2. Measure performance with the Python profiler. Fix any problems you find. Change data structures and algorithms as necessary to really do this properly. You'll finish this long before you finish the first version in C.

3. If it's still too slow, manually translate the well-designed and carefully constructed Python into C.

   Because of the way hindsight works, doing the second version from existing Python (with existing unit tests, and with existing profiling data) will still be faster than trying to do the C code from scratch.

This quote is important.

Thompson's Rule for First-Time Telescope Makers
It is faster to make a four-inch mirror and then a six-inch mirror than to make a six-inch mirror.

Bill McKeenan
Wang Institute

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.

That bytecode is either interpreted (note that there's a difference, both in theory and in practical performance, between interpreting directly and first compiling to some intermediate representation and interpret that), as with the reference implementation (CPython), or both interpreted and compiled to optimized machine code at runtime, as with PyPy.

For all practical purposes, bytecode is just a data structure that is convenient for an interpreter to use. The interpreter looks at each instruction in the byte code and immediately performs that action.

A simple interpreter for arithmetic expressions might look like this when written in Python:

bytecode = [
  {'type': 'const', 'value': 40},
  {'type': 'const', 'value': 2},
  {'type': '+'},
  {'type': 'print'},
]

stack = []

for instruction in bytecode:
  action = instruction['type']
  if action == 'const':
    stack.append(instruction['value'])
  elif action == '+':
    right = stack.pop()
    left = stack.pop()
    stack.append(left + right)
  elif action == 'print':
    print(stack.pop())
  else:
    raise TypeError(f'Unknown instruction type {action}')

That is, the interpreter checks the type of the type of the instruction and selects which code snippet to run depending on that action. The interpreter is not translating the bytecode into another language in the sense that we'd get a program in that language, but it does map the instructions to code snippets.

Thus, the CPython interpreter does not translate Python bytecode into C code, but selects which C code snippet to run depending on the instruction.

This is useful, because generating C code that works correctly and is as fast as expected from C is quite tricky. Interpreters typically spend a lot of time doing extra bookkeeping (like reference counting), and in the dispatch logic itself – that loop through all instructions isn't quite free.

Programs that translate a source language into another language are sometimes called a transpiler (a kind of compiler that doesn't output machine code). It is easy to create a transpiler that just calls into the code snippets of an interpreter (sometimes called threaded code in older literature):

bytecode = [
  {'type': 'const', 'value': 40},
  {'type': 'const', 'value': 2},
  {'type': '+'},
  {'type': 'print'},
]

# built-in function for our "compiled" code to call

def do_const(stack, value):
  stack.append(value)

def do_add(stack):
  right = stack.pop()
  left = stack.pop()
  stack.append(left + right)

def do_print(stack):
  print(stack.pop())

# assembling Python source code for our "bytecode"
code = 'stack = []\n'
for instruction in bytecode:
  action = instruction['type']
  if action == 'const':
    code += f'do_const(stack, {instruction["value"]})\n'
  elif action == '+':
    code += 'do_add(stack)\n'
  elif action == 'print':
    code += 'do_print(stack)\n'
  else:
    raise TypeError(f'Unknown instruction type {action}')

# we can now execute the code by "compiling" it as Python:
exec(code, locals(), {})

The resulting code might be slightly faster because we've gotten rid of the dispatch logic, but we still have interpreter overhead like stack manipulation. The code we've generated doesn't look like normal Python code. But to get to that Python code we still had to run through our dispatch logic, and now Python has to parse the code we've generated. Similarly, a Python interpreter that translates to C wouldn't be very fast.

The Java reference implementation OpenJDK/HotSpot is interesting because its runtime combines a just-in-time compiler with an interpreter. By default, it interprets byte code with an interpreter written in C++. But if the same code is executed often enough, it compiles that part of the code directly to machine code. Depending on how important that code is, HotSpot spends more effort on optimizing the machine code. This allows Java to be as fast as C in some benchmarks. CPython is very simplistic in comparison.

There is (was?) a Python implementation called Jython that was written in Java. Jython works by compiling the Python code to Java byte code. That byte code is then handled by the Java virtual machine, which either interprets it or compiles it on the fly to machine code, as discussed above. Because the Java runtime is awesome this could make that Python code run very fast, in some circumstances. But the added complexity also comes at a cost. Additionally, Jython is not compatible with Python modules that need to interact with internal CPython data structures.