Our discipline (computer programming) is, perhaps more than any other, one in which precision of meaning is of paramount importance. I expect people to hedge. Especially when it's easy: "Python is not usually compiled to native code."

In any case, since Python is virtually always compiled, saying it's not is simply false. That's hardly clear communication, I think.

> Obviously python is interpreted by any meaningful definition of interpretation ....

Now, here I'm not sure what you mean. You've already distinguished interpretation from Just-In-Time compilation to Virtual Machine code. Since the latter is pretty much always what happens with Python, would you then say that Python is not interepreted? (Serious question!)

Me, I don't have a problem with these concepts overlapping (and I don't see why many people do). Python is interpreted. The usual mechanism for this is JIT compilation to virtual-machine code, which is then -- in the case of CPython -- interpreted as-is. In contrast, something like "C" is traditionally Ahead-Of-Time (AOT) compiled to native code. Interpreted: no. Compiled: yes. And then there are languages whose interpreters do not involve a compilation step -- although they are becoming rare.

This is very different from Perl, where a line of code isn't parseable until you know the values of the variables, e.g.

    whatever / 25 ; # / ; die "this dies!";

Perl is crazy, but I don't think it's that crazy.

From perlcompile(http://perldoc.perl.org/5.8.9/perlcompile.html)

    Perl has always had a compiler: your source is compiled
    into an internal form (a parse tree) which is then optimized
    before being run.

I could not get your code sample to die based on the type/value of "whatever" -- can you?

Basically, you can't always parse a Perl program without running it. There is a subset that you can, not not everything.

That is true, but what the grandparent said is not: https://news.ycombinator.com/item?id=8626454

To expand on this, I think a succinct way of summarizing the issue is: you might have to run BEGIN blocks in Perl to parse the non-BEGIN-block part of the program. The canonical example of this is:

    BEGIN {
        if(arbitrary_function()) {
            eval "sub whatever() { }; 1" or die $@;
        } else {
            eval "sub whatever { }; 1" or die $@;
        }
    }

    # The parsing of this line depends on the result of arbitrary_function()
    whatever  / 25 ; # / ; die "this dies!";

Grandparent said "This is very different from Perl, where a line of code isn't parseable until you know the values of the variables."

If that were true, it would imply that you could have a loop whose body is parsed differently on every iteration. It would imply that the parser runs inline with the interpreter. Neither of those things are true.

What your link says is that the parsing can vary based on whether or not a subroutine prototype with appropriate arity was previously defined. That is a very different thing. A statement in a loop could be parsed differently depending on what was defined before it, but that parse doesn't change just because a subroutine is defined later, I'm pretty sure.

Yes, this means Perl's parsing is undecideable, because you can conditionally define a subroutine (this might be limited to BEGIN blocks; I'm not sure). But that's not the same as saying the parse varies based on the "values of the variables."

  [13:06:36] ~$perl -e 'whatever / 25 ; die "this dies!";'
  this dies! at -e line 1.
  [13:06:36] ~$

  [13:06:38] ~$perl -e "use strict; use warnings; whatever / 25 ; die "this dies!";"
  Useless use of division (/) in void context at -e line 1.
  Bareword "whatever" not allowed while "strict subs" in use at -e line 1.
  Execution of -e aborted due to compilation errors.
  [13:06:38] ~$

Because CPython implements its virtual machine with an interpreter, without the option of, say, a JIT compiler.