Is Python interpreted (like Javascript or PHP)?
Question:
Is Python strictly interpreted at run time, or can it be used to develop programs that run as background applications (like a Java app or C program)?
Answers:
Yes, Python is interpreted, but you can also run them as long-running applications.
There’s multiple questions here:
- No, Python is not interpreted. The standard implementation compiles to bytecode, and then executes in a virtual machine. Many modern JavaScript engines also do this.
- Regardless of implementation (interpreter, VM, machine code), anything you want can run in the background. You can run shell scripts in the background, if you want.
Python is an interpreted language but it is the bytecode which is interpreted at run time. There are also many tools out there that can assist you in making your programs run as a windows service / UNIX daemon.
Yes, it’s interpreted, its main implementation compiles bytecode first and then runs it though (kind of if you took a java source and the JVM compiled it before running it). Still, you can run your application in background. Actually, you can run pretty much anything in background.
Technically, Python is compiled to bytecode and then interpreted in a virtual machine. If the Python compiler is able to write out the bytecode into a .pyc file, it will (usually) do so.
On the other hand, there’s no explicit compilation step in Python as there is with Java or C. From the point of view of the developer, it looks like Python is just interpreting the .py file directly. Plus, Python offers an interactive prompt where you can type Python statements and have them executed immediately. So the workflow in Python is much more similar to that of an interpreted language than that of a compiled language. To me (and a lot of other developers, I suppose), that distinction of workflow is more important than whether there’s an intermediate bytecode step or not.
As the varied responses will tell you, the line between interpreted and compiled is no longer as clear as it was when such terms were coined. In fact, it’s also something of a mistake to consider languages as being either interpreted or compiled, as different implementations of languages may do different things. These days you can find both C interpreters and Javascript compilers.
Even when looking at an implementation, things still aren’t clear-cut. There are layers of interpretation. Here are a few of the gradations between interpreted and compiled:
-
Pure interpretation. Pretty much what it says on the tin. Read a line of source and immediately do what it says. This isn’t actually done by many production languages – pretty much just things like shell scripts.
-
Tokenisation + interpretation. A trivial optimization on the above. Rather than interpret each line from scratch, it’s first tokenized (that is, rather than seeing a string like "print 52 + x", it’s translated into a stream of tokens (eg. [PRINT_STATEMENT, INTEGER(52), PLUS_SIGN, IDENTIFIER('x')] ) to avoid repeatedly performing that state of interpretation. Many versions of basic worked this way.
-
Bytecode compilation. This is the approach taken by languages like Java and C# (though see below). The code is transformed into instructions for a "virtual machine". These instructions are then interpreted. This is also the approach taken by python (or at least cpython, the most common implementation.) The Jython and Ironpython implementations also take this approach, but compile to the bytecode for the Java and C# virtual machines respectively.
-
Bytecode + Just in Time compilation. As above, but rather than interpreting the bytecodes, the code that would be performed is compiled from the bytecode at the point of execution and then run. In some cases, this can actually outperform native compilation, as it is free to perform runtime analysis on the code, and can use specific features of the current processor (while static compilation may need to compile for a lowest common denominator CPU). Later versions of Java, and C# use this approach. Psyco performs this for python.
-
Native machine-code compilation. The code is compiled to the machine code of the target system. You may think we’ve now completely eliminated interpretation, but even here there are subtleties. Some machine code instructions are not actually directly implemented in hardware, but are in fact implemented via microcode – even machine code is sometimes interpreted!
Is Python strictly interpreted at run time, or can it be used to develop programs that run as background applications (like a Java app or C program)?
Yes, Python is interpreted, but you can also run them as long-running applications.
There’s multiple questions here:
- No, Python is not interpreted. The standard implementation compiles to bytecode, and then executes in a virtual machine. Many modern JavaScript engines also do this.
- Regardless of implementation (interpreter, VM, machine code), anything you want can run in the background. You can run shell scripts in the background, if you want.
Python is an interpreted language but it is the bytecode which is interpreted at run time. There are also many tools out there that can assist you in making your programs run as a windows service / UNIX daemon.
Yes, it’s interpreted, its main implementation compiles bytecode first and then runs it though (kind of if you took a java source and the JVM compiled it before running it). Still, you can run your application in background. Actually, you can run pretty much anything in background.
Technically, Python is compiled to bytecode and then interpreted in a virtual machine. If the Python compiler is able to write out the bytecode into a .pyc file, it will (usually) do so.
On the other hand, there’s no explicit compilation step in Python as there is with Java or C. From the point of view of the developer, it looks like Python is just interpreting the .py file directly. Plus, Python offers an interactive prompt where you can type Python statements and have them executed immediately. So the workflow in Python is much more similar to that of an interpreted language than that of a compiled language. To me (and a lot of other developers, I suppose), that distinction of workflow is more important than whether there’s an intermediate bytecode step or not.
As the varied responses will tell you, the line between interpreted and compiled is no longer as clear as it was when such terms were coined. In fact, it’s also something of a mistake to consider languages as being either interpreted or compiled, as different implementations of languages may do different things. These days you can find both C interpreters and Javascript compilers.
Even when looking at an implementation, things still aren’t clear-cut. There are layers of interpretation. Here are a few of the gradations between interpreted and compiled:
-
Pure interpretation. Pretty much what it says on the tin. Read a line of source and immediately do what it says. This isn’t actually done by many production languages – pretty much just things like shell scripts.
-
Tokenisation + interpretation. A trivial optimization on the above. Rather than interpret each line from scratch, it’s first tokenized (that is, rather than seeing a string like "print 52 + x", it’s translated into a stream of tokens (eg.
[PRINT_STATEMENT, INTEGER(52), PLUS_SIGN, IDENTIFIER('x')]) to avoid repeatedly performing that state of interpretation. Many versions of basic worked this way. -
Bytecode compilation. This is the approach taken by languages like Java and C# (though see below). The code is transformed into instructions for a "virtual machine". These instructions are then interpreted. This is also the approach taken by python (or at least cpython, the most common implementation.) The Jython and Ironpython implementations also take this approach, but compile to the bytecode for the Java and C# virtual machines respectively.
-
Bytecode + Just in Time compilation. As above, but rather than interpreting the bytecodes, the code that would be performed is compiled from the bytecode at the point of execution and then run. In some cases, this can actually outperform native compilation, as it is free to perform runtime analysis on the code, and can use specific features of the current processor (while static compilation may need to compile for a lowest common denominator CPU). Later versions of Java, and C# use this approach. Psyco performs this for python.
-
Native machine-code compilation. The code is compiled to the machine code of the target system. You may think we’ve now completely eliminated interpretation, but even here there are subtleties. Some machine code instructions are not actually directly implemented in hardware, but are in fact implemented via microcode – even machine code is sometimes interpreted!