Python Front-end to GCC

[Philip Herron]

On Tuesday, 22 October 2013 09:55:15 UTC+1, Antoine Pitrou  wrote:
> Philip Herron <herron.philip <at> googlemail.com> 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.
> 
> 
> 
> 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.).
> 
> 
> 
> Regards
> 
> 
> 
> Antoine.
Thanks for that interesting example, i haven't looked into how its implemented but on initially looking at this is am nearly sure i can implement this without using exec or eval. I've found this a lot in implementing my run time. Exec and eval at least to me in the past I've used them as debug hooks into a toy virtual machine i wrote i don't particularly think they are part of a language nor should people really use them.

Thanks