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

[logistix]

Okay,

Here's a summary of what I'm seeing:
	An ExecutionContext object is created. This is a stack of
frames.
	A PyFrame is created.  This has no knowledge of frames above it
on the stack.
	The ExecutionContext accepts the PyFrame for evaluation, and
calls the PyFrame's eval passing itself in as a parameter.
	The PyFrame's eval method just treats the ExecutionContext as a
local var, it isn't stored in the class.
	PyFrame calls appropriate bytecode implementation functions,
passing itself as a parameter.
	bytecode implementation functions are unaware of the execution
context.

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.  Also, nested scope references can't be resolved
for the same reasons.  Trying this in the interactive interpreter dies
hard.  I'm sure there are other issues as well.

So do we eliminate the ExecutionContexts and add a "parent frame"
property to PyFrame, or do we store a ref to the ExecutionContext as a
PyFrame property, or do something else completely?