>You have probably already heard that Python, unlike Fortran, C++ or Go, was an interpreted language. While not completely wrong, it is not entirely true either.

Interpreted byte-code is still interpreted (and is a norm among interpreted languages: VB (pcode), PHP, Perl, some Pascal, Java (until the JIT gets to it) all interpreted byte-code.)

I really dislike it when people change the definitions of well established things because they don't like their own, or others, connotations of the term.

>Thereafter, these instructions are actually interpreted by a virtual machine.

Indeed like most other mainstream interpreters do...

CPython is both compiled and interpreted. His point was that the Python source code does not get interpreted, it gets compiled to bytecode that gets interpreted by a bytecode interpreter (a VM).

He was dispelling the common misconception is that Python is an "interpreted language" and Java is a "compiled language," when the reality is that (in their most common implementations) both of these languages are compiled to bytecode that is then interpreted by a VM.

This is in contrast to both languages that are purely interpreted (like toy Lisp implementations are and I think Ruby MRI used to be) as well as languages that are purely compiled to native binaries (like C/C++, Haskell, Go).

>His point was that the Python source code does not get interpreted, it gets compiled to bytecode that gets interpreted by a bytecode interpreter (a VM).

My point was almost every mainstream interpreter does this (and has been for decades). So him saying "Python... was an interpreted language. While not completely wrong, it is not entirely true either." is confusing and inaccurate. It is completely true that Python is interpreted (and like almost every other interpreted language its the bytecode that is interpreted not the source code).

When I was doing my undergrad we had an assignment to write an interpreter, at the end of class our new assignment was to make it 10x faster. So we did this by converting the parse tree to bytecode rather than directly executing it as it parsed. It wasn't hard or advanced work.

While I'm with you on the definition point (it is interpreted) I fail to see the relevance of that last paragraph??

User voidlogic was pointing out that converting to bytecode before interpreting was so mainstream (and relatively simple) that even undergraduate students do it for an assignment.

Yes, this exactly. I should have been more direct.

> He was dispelling the common misconception is that Python is an "interpreted language" and Java is a "compiled language," when the reality is that (in their most common implementations) both of these languages are compiled to bytecode that is then interpreted by a VM.

Good example of how you can take an issue and confuse it even more with tricky use of words, however despite both Java and Python have a VM, and despite both have bytecode, they're at the different ends of the spectrum from "naively interpreted from source" to "fully compiled".

It helps that Java was designed in a way that allows most of the code to be JIT compiled, which leaves interpreting for a few edge cases.

That's less important of a distinction when you consider that Python has a JIT implementation too (PyPy).

No, it's still an important distinction, because there's a lot less to JIT in Python, compared to Java, which is why I specifically mentioned that bit.

And to prove my point just bench PyPy against Java on any given machine of your choice, and then come back to tell me if the distinction is important enough.

Last I checked, (granted, late 1990s) the Perl 5 interpreter was actually an AST-walking interpreter, without an internal bytecode. It had a bytecode for serializing ASTs to disk, but that wasn't useful for much other than obfuscation because reconstituting the AST from the bytecode was actually slower than parsing source.