Why is it impossible to create a compiler than can compile Python to machinecode like C?
Terry Reedy
tjreedy at udel.edu
Mon Mar 4 19:31:09 EST 2013
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
More information about the Python-list
mailing list