Well, let's be clear here.
When you compile C, say, you're making machine code. (Same if you compile something down to C and then compile that.) Machine code is way fast. And it's heavily optimised, too, which is why compiling lots of C can take a lot of CPU, and that's why you do it once and then run the result over and over.
When you compile Python, Perl, Java, etc., you're producing bytecode. You still need a virtual machine (compiled machine code) to handle all the instructions (compiled bytecode), so it won't be as fast as pure machine code, but at least you don't need to process the raw source code over and over.
Note that some of these require a compiling step beforehand (e.g. Java), some don't but leave behind the compiled code for next time (e.g. Python), and some just recompile the code to memory every time you launch it (e.g. Perl). The effect is always the same -- you've got a virtual machine running compiled bytecode. (Someday, they may all actually run under
the same VM.)
So note that although Python is compiled, it's not going to be as fast as a C-based language. Something like Lua, compiled down to C, could be a fair bit faster (assuming it's producing efficient C code).
That being said, I don't personally have a problem with an interpreted run-time-compiled scripting language like Python, so long as it doesn't become bloated or overworked. When code gets complex and/or is being run so often that it's a significant performance drain, then it's time to either slim things up or port code into the C++ core.
(Also, although I'm not a fan of Python myself, at least it's one of the big names that everyone knows; I'm not sure I can say the same for something like Lua. Of course, some of the best languages out there are also the most esoteric.
)
