Python Front-end to GCC

[Stefan Behnel]

Antoine Pitrou, 22.10.2013 10:55:
> Philip Herron writes:
>> Its interesting a few things come up what about:
>> exec and eval. I didn't really have a good answer for this at my talk at
>> PYCon IE 2013 but i am going to say no. I am
>> not going to implement these. Partly because eval and exec at least to me
>> are mostly from developing
>> interpreters as a debugging exercise so the test doesn't have to invoke
>> the program properly and feed in
>> strings to interpret at least thats what i have done in the past with an
>> virtual machine i wrote before gccpy.
> 
> If you don't implement exec() and eval() then people won't be able to use
> namedtuples, which are a common datatype factory.

FWIW, for Cython, I personally consider eval() and exec() more of a handy
way to insert plain Python code (potentially even generated at runtime)
into compiled code, so they are not currently compiled. You can see that
from the low Mako benchmark results, for example. We may eventually add an
option to compile that code at runtime (assuming you have Cython and a C
compiler installed), but I doubt that people would want that as the default.

Obviously, Cython has the advantage of being backed by a CPython runtime,
so it's easy for us to choose one or the other. An independent Python
implementation doesn't easily have that choice.


> As for the rest: well, good luck writing an AOT compiler producing
> interesting results on average *pure* Python code. It's already been tried
> a number of times, and has generally failed. Cython mitigates the issue by
> exposing a superset of Python (including type hints, etc.).

Agreed, although the word "mitigate" makes it sound more like a work-around
than the actual feature it represents. I've written down my thoughts on
this topic a while ago.

http://blog.behnel.de/index.php?p=241

Stefan