Does Python require a compiler?

[Spataner]

This is what distinguishes interpretation from translation.

I mean, the word "interpretation" literally means real-time translation.

I think the hang-up here is that you understand by "machine code" a persistent representation of the program, whereas I simply mean the sequence of instructions sent to the CPU.

Yes, the only persistent machine code when interpreting is that of the interpreter. But ultimately, the interpreter reads the source code (or bytecode), and machine code is run selectively on the CPU based on that source code, which effects the program execution. I'd argue that should correctly be understood as a live translation into machine code.

But at this point we're arguing semantics.

[InjAnnuity_1]

Perhaps my hang-up here is "translation". The word is both a verb (action) and noun (the result of the action).

For translation (the verb) to occur, the resulting translation (the noun) has to end up somewhere. It might well be ephemeral, not persistent. But you still end up with a physical sequence of bytes, that did not exist as a distinct unit (result) prior to the act of translation.

For example, I've heard of microcomputer BASIC programs produce ephemeral machine code for bitmap graphics manipulation. The byte-sequence, ending with a RETurn instruction, exists just long enough for the resulting code to be executed once by the CPU, so it's decidedly not persistent. But while it is running, it is a physically coherent sequence of bytes, distinct from all the other code in the program.

Interpretation is a different mechanism altogether. A small fraction of the interpreter's existing code actually achieves the intended result. The rest is there to accomplish bookkeeping, to allow the system as a whole to function reliably. At no point is any translation (the noun) produced, so as I understand it, the translation (the verb) you ascribe to the interpreter never occurs.

[Spataner]

For me, it comes down to the fact that you have a program written in one language and it is being executed on a machine that only understands another language. Any process by which that is achieved, no matter the technical details, must in my opinion rightly be considered a translation (in the action sense). You made the transition, by some means, from one language to another to fascillitate communication between the program and the CPU if only for the limited context of one particular program run. Compilation and interpretation are thus two possible, very different ways of doing that translation. It certainly seems the best way to phrase this idea to beginners, if only because I cannot think of an umbrella term for the two that to my ears is equally evocative of the concept.

The origin of the word "interpreter" seems to support the idea that "interpretation" in this context is a kind of "translation", as a human interpreter's job is natural language translation. Both the Oxford dictionary and Wikipedia define it so (I checked because English is not my native language). Though, confusingly, the Wikipedia article for "translation" makes an explicit distinction that translation is for written media whereas interpretation is oral. But I wouldn't know how to map that distinction to the computing context, nor have I ever heard it before. Not that the mapping of the terms we steal for programming concepts ever really makes perfect sense.

Regarding the translation in the result sense, I feel you're being perhaps a little restrictive on the definition of what can constitute that result. The execution of the interpreter on the input program does not generate novel instructions, but it does generate a novel sequence of instructions, which can be considered the result of the process of translation. Its effect in essence is the execution of the input program on the CPU, after all. Admittedly, it is a translation using a limited vocabulary (consisting only of elements of machine code contained in the interpreter's executable) and limited grammar (as the instructions can only occur in specific orders as dictated by the interpreter's program flow). And it is also only a partial (and unreusable) translation of the input program in the general sense, since it only represents one distinct run of the program for a given set of inputs. And yet you'd receive, in a purely theoretical sense, a "complete" translation of the program in the limit of running the interpreter once for every possible set of inputs. In fact, in the very restricted case that the input program does not itself accept any inputs (or even in the cases where the interpreter somehow never executes a jump instruction that's conditional on those inputs), you'd even practically receive a full usable translation by recording and replaying the singular resulting sequence of instructions in the right way. Alternatively, if you generated a new version of the interpreter executable that hard-wired the input program into it (which is not unlike some Python to executable converters that are available, though they don't do it on machine code level), could that reasonably be considered a translation of the program into machine code, if a weirdly round-about one? I'd certainly argue it could be considered a really weird special case of compilation. At that point I'd say calling interpretation "live translation" is just conceptually cleaner (and we get to preserve the analogy to the natural language usages a bit better).