Why is it impossible to create a compiler than can compile Python to machinecode like C?

[Terry Reedy]

On 3/4/2013 5:55 PM, CM wrote:

> Could you help me understand this better?  For example, if you
> have this line in the Python program:
>
> foo = 'some text'
> bar = {'apple':'fruit'}
>
> If the interpreter can determine at runtime that foo is a string
> and bar is a dict, why can't the compiler figure that out at
> compile time?  Or is the problem that if later in the program
> you have this line:
>
> foo = 12
>
> now foo is referring to an integer object, not a string, and
> compilers can't have two names referring to two different
> types of objects?

I believe you mean one name referring to multiple types.

> Something like that?

Something like that. In python, objects are strongly typed, names do not 
have types. Or if you prefer, names are typed according to their current 
binding, which can freely change. As for why this can be an advantage, 
consider this simple function.

def min2(a, b):
   if a <= b:
     return a
   else:
     return b

When the def statement is executed, the names 'a' and 'b' have no 
binding and therefore no type, not even a temporary type.

In a statically typed language, either you or the compiler must rewrite 
that function for every pair of types that are ever input to min2. If 
the compiler does it, it either has to analyze an entire program, or it 
have to compile variations on the fly, as needed. The latter is what the 
psycho module, and, I believe, the pypy jit compiler does.

-- 
Terry Jan Reedy