[pypy-dev] Re: [pypy-svn] rev 1121 - in pypy/branch/builtinrefactor/pypy:interpreter module module/test

[Michael Hudson]

Armin Rigo <arigo at tunes.org> writes:

> Some more refactoring would be nice here. I'm posting here something we
> discussed at the end of the latest sprint: from the point of view of decoding
> the arguments, a frame is just a repository of 'fast locals' slots. Hence the
> idea that instead of decoding arguments and building a real 'locals'
> dictionary, we directly put the arguments in a frame-like class. As it only
> makes sense to use a real PyFrame instance when we are about to call a Python
> (app-level) function, we could use a base class for the general case:
>
>  + ActivationFrame
>     + PyFrame        [the current frame class]
>     + BuiltinFrame
>
>  + ExecutableCode    [new proposed name for PyBaseCode]
>     + PyCode         [new proposed name for PyByteCode]
>     + BuiltinCode    [new proposed name for PyBuiltinCode]
>
> ExecutableCode instances are used as the 'func_code' attribute of function
> objects; they would have methods to create an ActivationFrame instance of the
> correct corresponding class, and then the ActivationFrame's list of 'fast
> locals' would be populated with the generic ExecutableCode.build_arguments().  
> The base ActivationFrame is essentially nothing more than a 'fast locals'
> container. It is easy to either use that as the real 'fast locals' during
> interpretation in PyFrame, or pick the arguments from the list in BuiltinFrame
> to pass them to the built-in interpreter-level function. I think it looks like
> a nice way to minimize the number of times the arguments must be copied
> around.

<aol>
me too
</aol>

Cheers,
M.

-- 
  Clue: You've got the appropriate amount of hostility for the
  Monastery, however you are metaphorically getting out of the
  safari jeep and kicking the lions.                         -- coonec
               -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html