Is Python Interpreted or Compiled?
This is just a wondering I had while reading about interpreted and compiled languages.
Ruby is no doubt an interpreted language since the source code is processed by an interpreter at the point of execution.
On the contrary C is a compiled language, as one have to compile the source code first according to the machine and then execute. This results is much faster execution.
Now coming to Python:
- A python code (somefile.py) when imported creates a file (somefile.pyc) in the same directory. Let us say the import is done in a python shell or django module. After the import I change the code a bit and execute the imported functions again to find that it is still running the old code. This suggests that *.pyc files are compiled python files similar to executable created after compilation of a C file, though I can't execute *.pyc file directly.
- When the python file (somefile.py) is executed directly ( ./somefile.py or python somefile.py ) no .pyc file is created and the code is executed as is indicating interpreted behavior.
These suggest that a python code is compiled every time it is imported in a new process to create a .pyc while it is interpreted when directly executed.
So which type of language should I consider it as? Interpreted or Compiled? And how does its efficiency compare to interpreted and compiled languages?
According to wiki's Interpreted Languages page, it is listed as a language compiled to Virtual Machine Code, what is meant by that?
When is there doubt as to whether Ruby is an interpreted language? When it's compiled. :) http://www.macruby.org/
It is worth noting that no modern language is interpreted in the strict sense. Virtually all of them compile to bytecode.
@Winston Ewert: bravo! Applesoft Basic (in 1980's) was byte-code compiled. "modern" in this case, means every interpreted language in living memory with the only possible exception being some rudimentary Dartmouth Basic implementations.
@S.Lott, I have run into some which appear to be actually interpreted. These are typically internal scripting languages of applications.
@Winston Ewert: That's okay. Your original point that almost everything is byte-code compiled was spot on. The presence of "internal scripting languages of applications" that somehow bypass byte-code compilation isn't really relevant. The question is about Python and other very-widely used languages.
>> On the contrary C is a compiled language << http://root.cern.ch/drupal/content/cint
@S.Lott: Calling the tokenization process that Applesoft and '80s BASIC interpreters did "bytecode compilation" is more than a little disingenuous. Yes, the program code entered by the user was stored in memory in a compressed form, one byte per reserved word, but nothing was done beyond that until you typed `RUN`. It was as if you had a compiler that did the lexing step and then output a stream of tokens that had to be reparsed every time the program was run. Not at all like modern bytecode compilation as done by, say, `javac`, which encompasses lexing, parsing, and optimization.
precompiled raw machine code is not by default faster than a good interpreter
"On the contrary C is a compiled language, as one have to compile the source code first according to the machine and then execute.": Nope, I once used a C interpreter to do some experiments.
It's worth noting that languages are not interpreted or compiled, but rather language implementations either interpret or compile code. You noted that Ruby is an "interpreted language", but you can compile Ruby à la MacRuby, so it's not always an interpreted language.
Pretty much every Python implementation consists of an interpreter (rather than a compiler). The
.pycfiles you see are byte code for the Python virtual machine (similar to Java's
.classfiles). They are not the same as the machine code generated by a C compiler for a native machine architecture. Some Python implementations, however, do consist of a just-in-time compiler that will compile Python byte code into native machine code.
(I say "pretty much every" because I don't know of any native machine compilers for Python, but I don't want to claim that none exist anywhere.)
Depending on your definition, native machine compilers for Python exist. Some only compile a subset of python. Others implement all of python but use the python API to actually perform the operations which it cannot perform in C.
I think you're actually describing that Python is either what I would call 'semi-compiled', or can actually be full compiled. By semi-compiled I mean that since it is usually compiled to the 'intermediate language' .pyc file that is used by the Python Virtual Machine, it is usually being run from this 'semi-compiled' form, that generally makes code faster than plain run-time interpretation of interpreted code. Interestingly, semi-compiled code can sometimes be faster than natively compiled code (e.g. C# is generally faster than C++).
Distinguishing byte code and machine code in this fashion is pretty arbitrary. Java is compiled: the javac compiler produces class files containing low level instructions that may be executed, either in a virtual machine (eg hotspot) or directly by hardware (e.g. on ARM processors with the Jazelle extension). As far as I know, there is no technical reason a similar processor architecture couldn't be designed to directly execute python vm instructions.
@Jules Coincidentally, Jython code is actually compiled in to .class files which I believe are reused until you modify the py source.
thx !! Just got bit confused with two statements _Some Python implementations, however, do consist of a just-in-time compiler that will compile Python byte code into native machine code_ **AND** _I say "pretty much every" because I don't know of any native machine compilers for Python, but I don't want to claim that none exist anywhere_ I assume you referring to same thing - Compilers to convert python to python byte code and then python virtual machine to convert from byte code to native code. Isn't it ?