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

Armin Rigo arigo at tunes.org
Wed Mar 5 08:13:58 CET 2003


On Wed, Mar 05, 2003 at 02:28:11AM +0100, Christian Tismer wrote:
> >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.

> The ec acts somehow like frame.f_tstate . If we call this a
> threadstate or an executioncontext, it is obviously needed.

Makes sense. Maybe not in the constructor of frames, but in their eval() 
method that could save the incoming executioncontext parameter for the 
duration of the call. (Might be cleaner for frames corresponding to generators 
if these are run in different executioncontexts during their lifetime.)

> > Frame.space.getexecutioncontext()
> >seems like you're running in circles. 

Yes. The point of getexecutioncontext() was actually to get back to the 
calling frame or executioncontext when you are in the object space itself, 
e.g. to implement function call. For the frame opcodes, it is overkill.

A bientot,


More information about the Pypy-dev mailing list