> The compiler should be able sift through the code and see that "x=1" is an integer, or converts to a float when "x=x+1.0".
The short version is "no, it shouldn't".
The longer version is that, viewing Python's runtime class memberships as "types", the type system it would represent is not one for which inference without explicit declarations is generally decidable, so an AOT compiler for unmodified, unrestricted Python that is expected to infer types at runtime simply would not be possible.
You could AOT compile it into C code with a lot of runtime metadata and indirections -- but that would probably have worse performance than the existing interpreter.
> Way back when, you could get a BASIC compiler to turn your interpreted BASIC code into assembly.
Well, yeah, BASIC is actually structurally quite close to assembly. Its not a dynamically-typed multiparadigm language like Python.
Its hard to be worse than an interpreter. 100X slower than compiled code is typical. Whatever 'metadata and indirection' your C target has, it seems likely to be 10X better than interpreted, easily.
Cython is a very mature python-to-C translator and it offers 0-40% speed improvements in my experience on straight Python. To get any significant speedups you have to add type declarations, replace python function with equivalent C functions from the standard library, turn off bounds checking and bunch of similar things. But if you do that then it does produce some pretty fast code.
Its actually quite easy to be worse than an interpreter that is actually a combination of a bytecode compiler and a VM built around the execution model of the language it is for, which is what the main Python interpreter is.
The short version is "no, it shouldn't".
The longer version is that, viewing Python's runtime class memberships as "types", the type system it would represent is not one for which inference without explicit declarations is generally decidable, so an AOT compiler for unmodified, unrestricted Python that is expected to infer types at runtime simply would not be possible.
You could AOT compile it into C code with a lot of runtime metadata and indirections -- but that would probably have worse performance than the existing interpreter.
> Way back when, you could get a BASIC compiler to turn your interpreted BASIC code into assembly.
Well, yeah, BASIC is actually structurally quite close to assembly. Its not a dynamically-typed multiparadigm language like Python.