[pypy-dev] Why is there a separate ExecutionContext?

logistix vze55z8s at verizon.net
Tue Mar 4 23:54:44 CET 2003

> -----Original Message-----
> From: pypy-dev-bounces at codespeak.net 
> [mailto:pypy-dev-bounces at codespeak.net] On Behalf Of Armin Rigo
> Sent: Tuesday, March 04, 2003 2:50 AM
> To: pypy-dev at codespeak.net
> Subject: Re: [pypy-dev] Why is there a separate ExecutionContext?
> Hello Logistix,
> On Mon, Mar 03, 2003 at 07:25:25PM -0500, logistix wrote:
> > This causes a few problems.  First of all, it's impossible to 
> > implement the EXEC_STMT bytecode, because you can't call a 
> PyFrame's 
> > eval() from inside a bytecode function since you don't have an 
> > executionContext to pass in as a parameter.
> This has been discussed and argued over at the sprint: the 
> few functions that 
> actually want to come back to the execution context or to the 
> frame can use 
> the getexecutioncontext() method. It was juged preferable to 
> add this hack 
> instead of passing an extra argument to *all* functions 
> around. Consider it as 
> an extra hidden parameter.

Would it be semantically clearer if PyFrames got an executioncontext
object in the constructor instead of the space object?  Space could
still be accessed via frame.ec.space.  Frame.space.getexecutioncontext()
seems like you're running in circles. 

More information about the Pypy-dev mailing list