> "Python is an interpreted, object-oriented, high-level programming language with dynamic semantics."
I have an issue with that statement. No languages are inherently "compiled" or "interpreted", that's a property of the implementation.
If we are talking about CPython here, Python code is compiled to bytecode which is then interpreted. Not unlike Java - with the difference that the main implementation has a JIT and afaik, Python's does not.
But that's CPython. What about PyPy? It has a JIT.
> No languages are inherently "compiled" or "interpreted", that's a property of the implementation.
A language and it's implementation are usually designed at the same time. Compiled or interpreted will affect design choices that go into the language. While additional implementations may follow, it can be hard/impossible to design a compiler (machine code, not byte code) for a language that was designed to be interpreted without dropping features (ie eval).
It may be more correct to say 'Python was designed to be interpreted' than 'Python is interpreted'
Not really - Javascript was designed to be interpreted, and yet V8/SpiderMonkey/Nitro all JIT-compile it down to machine code, sometimes very effectively.
Then Java and .NET are considered "interpreted"? And Android under Dalvik is "interpreted", but under ART is "compiled" (using Java as the language, which I'd always thought of as compiled, yet apparently is interpreted under your definition)? What if you embed Clang & LLVM in your application to run C++?
I think this just illustrates the fuzziness of these definitions. A compiler is just a piece of code; you can embed it into another piece of code and run it whenever necessary. Maybe in the world of shrink-wrapped desktop software there was a sharp distinction between AOT compiled languages and interpreted ones, but we haven't lived in that world for a couple decades now.
I feel that what most people actually mean when they say "compiled" vs. "interpreted" is whether or not the language specification has additional static checking beyond what is required by parsing. Essentially it is whether the language defers all errors to run-time or attempts to detect classes of them at compile-time. A language like JavaScript accepts as a program any string that parses, while a language like Java rejects many strings based on additional checks such as type rules. You can add static type-checking to JavaScript or Python, but it isn't part of the language spec. You can run C++ or Java with run-time type-checking, but it doesn't conform the to spec. In this way you could say that the language is fundamentally compiled or interpreted.
Of course, this doesn't address issues of incremental evaluation which often requires additional semantics for compiled languages.
Let's just say that the lines got a lot blurrier over the last couple of decades. The difference is generally if there's an explicit compilation step that is not hidden from developers. If you "run the source file", then it's interpreted. If you "run something generated from the source file(s)", then it's compiled. Stronger type checking and compiled mode is likely since the cost of compilation is higher and more resource intensive, so it makes sense to push it into an offline step.
> You can run C++ or Java with run-time type-checking, but it doesn't conform the to spec.
I'm not sure what you mean by "conforming with the spec". You can opt out of type checking by using only `object` or `void*`. But golang has a mode where you run a go file directly and a mode where you generate a binary. There are no traditional interpreted languages anymore (or at least only very few). And what we call "compiled" languages today are not actually compiled ones. The way Java runs is closer to how JavaScript runs than to how C runs. It's only about the interface the offer to developers.
That's technically true, but I still think it's reasonable to casually refer to Python as "interpreted," since it conveys useful ideas, although those ideas are more accurately conveyed with different phrasing.
That said, for more precise discussions, what you pointed out is valid and important. One of the early questions I ask in a programming interview is to explain some high-level differences between two languages they're familiar with, which is often Java and Python. One of the common responses I get is that Java compiles to bytecode which is executed by a VM, while Python is interpreted. Of course, I point out that CPython is also compiled to bytecode and executed by a VM.
I think its reasonable to refer to the reference implementation of Python (CPython) as just "Python". The compilation to bytecode is an intermediate step because Python specifies a virtual machine. The language is definitely interpreted though. Its completely accurate to call Python an interpreted language. There's no version of Python that I know of (including PyPy) that ever produces compiled machine executable binaries prior to runtime.
The compiled vs. interpreted thing is kind of a historical relic that people still cling on to. It's not dissimilar to where one draws the line for "scripting" or "nth generation" languages; it's all somewhat nebulously defined.
From my experience, the only time I've heard it nowadays is from people who were taught how to code by people who haven't coded since at least the 80s and never went on to develop the skill either professionally or as a hobby. So, yes, very much a historical relic!
That's right, in most Python implementations there's a "compiled" part (generally to bytecode) and then an "interpreted" one to run that bytecode. PyPy is a good example of a Python interpreter built on top of RPython (compiled with RPython, that is) adding a JIT to it.
High-level is also a relative term (with multivariable semantic, leading to not comparable languages), and the term "object-oriented" is getting less expressive by the day.
Anyway, all of those terms do communicate something, even if tomorrow they may wrongly describe the language.
I have an issue with that statement. No languages are inherently "compiled" or "interpreted", that's a property of the implementation.
If we are talking about CPython here, Python code is compiled to bytecode which is then interpreted. Not unlike Java - with the difference that the main implementation has a JIT and afaik, Python's does not.
But that's CPython. What about PyPy? It has a JIT.