[pypy-dev] Why is there a separate ExecutionContext?
tismer at tismer.com
Wed Mar 5 02:28:11 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
>>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.
I think this makes sense.
The ec acts somehow like frame.f_tstate . If we call this a
threadstate or an executioncontext, it is obviously needed.
ciao - chris
Christian Tismer :^) <mailto:tismer at tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
More information about the Pypy-dev