Why Are There So Many Pythons?

Pypy does have tooling to convert a limited subset of python ( they call it RPython) into an exe.

I'm a little rusty on the details, but IIUC the core of PyPy is an "abstract interpreter" for a restricted subset of Python known as RPython. Abstract interpretation is essentially a fold (in the functional programming sense) of the IR for a language, where you can parameterize the particular operation applied to each node. When the operation specified is "evaluate", you get partial evaluation, as described in the Wikipedia article.

The interesting part of PyPy happens when the RPython program to be evaluated is itself a Python interpreter, which it is. In this case, 'prog' is the Python interpreter written in RPython, and Istatic is your Python program. The first Futamura projection will give you a JIT; you specialize the RPython interpreter with your particular program, and it evaluates everything statically known at compile time (namely, your program) and produces an executable.

The second Futamura projection will give you a JIT compiler. Remember, since RPython is a subset of Python, an interpreter for Python written in RPython could be interpreted by itself. Moreover, it could be compiled by itself by the process described in the paragraph above. When you compile your JIT through the same process, you get a program that means the same thing (i.e. it will translate a Python program into an executable) but runs faster. The PyPy JIT that everybody's excited about for running Python scripts faster is this executable.

The third Futamura projection involves running PyPy on the toolchain that generated PyPy. Remember, this whole specializer machinery is all written in RPython, which can be interpreted by itself. So when your run the specializer machinery through itself, you get - an optimized toolset for building JIT compilers. That's what made programming language theorists excited about PyPy long before the Python community was. It's not just "faster Python", but it's a toolset for building a JIT out of anything you can build an interpreter for. Write an interpreter in RPython - for anything, Ruby, PHP, Arc, whatever - and run it through the PyPy toolchain, and it will give you a JIT compiler.

Hell, I would call Python's own 2to3 tool a compiler: it generates a full parse tree using a grammar, it runs some translation rules, and it generates Python 3 code.

The inferred languages just have this dude that watches your code and says, "yeah, I understand what is going on, your stuff is internally consistent"

Which is unfortunate, because now we dance through phrases like "things like Python and Ruby". There is a hard-to-precisely-define category here, and it's useful to have a name for it--even if the name is flawed.

And, in my opinion, it's usually better to hang on to an old name as it becomes less and less literally true than to continually fish about for a new name. ("Dynamic language" is popular now, but what happens when someone popularizes such a language with static typing?) As an analogy, consider "touchdown" in American football. You haven't had to touch the ball down to score in my lifetime, or even in my parents lifetimes, but we still call it a "touchdown" and not a "planebreaker".

No, it means the language is interpreted instead of being compiled to native code AOT.

You're ignoring context, which is a fundamental design decision in Perl. That's like criticizing C for having pointers while ignoring the design decision to expose memory as a flat space.

    #!/usr/bin/perl 
    use strict; 

    ++$a{$x}; 

    Global symbol "%a" requires explicit package name at ./test3.pl line 4.
    Global symbol "$x" requires explicit package name at ./test3.pl line 4.

    #!/usr/bin/perl 
    use strict; 

    my %foo = (batz => undef); 

    for (qw(bar batz)){ 
        if(exists($foo{$_})){ 
            print "$_ exists!\n"; 
            if(defined($foo{$_})){ 
                print "and $_ is defined.\n"; 
            }
            else { 
                print "and $_ is undefined.\n"; 
            }
        }
        else { 
            print "$_ doesn't actually exist\n"; 
    
        }
    }

    bar doesn't actually exist
    batz exists!
    and batz is undefined.

The solution to this is to use the autodie pragma (https://metacpan.org/pod/autodie) which has been part of the Perl core since 5.10.1 (released in Aug 2009):

  use 5.016;
  use warnings;
  use autodie;

  open my $fh, '<', "somefile";   # this file doesn't exist

And autodie is lexically scoped so it won't break any library code.