Limits of Metaprogramming
castironpi
castironpi at gmail.com
Mon Aug 4 16:23:43 EDT 2008
On Aug 4, 1:57 pm, Wilson <PaulAlexWil... at gmail.com> wrote:
> On Aug 4, 6:49 pm, castironpi <castiro... at gmail.com> wrote:
>
> > Two, if all your methods will have uniform signatures and closures,
> > you can store class methods as only their co_code objects:
>
> > >>> C.g.im_func.func_code.co_code
>
> > 'd\x00\x00S'
>
> > And fabricate them dynamically into full live types as needed.
>
> Thanks for your comments and advice. This second option intrigues me;
> could you elaborate further, I don't follow you...
>
> Thanks Paul
Depending on the complexity of the functions, a code string could be
all you need to store to determine (redetermine) a function's
behavior. For something moderately simple,
def trans1( self, prev, trans ):
if prev== 0 and trans== 'a':
return 1
if prev== 1 and trans== 'b':
return 0
return prev
I found you need to store code.co_nlocals, code.co_code, and
code.co_consts, to distinguish from a blank stub. With extra
variables, I needed code.co_names and code.co_varnames too. To
recreate a code object completely, you need 12 variables (14 to
include closures), some of which are composite objects and would need
to be pickled to be stored.
Then you can build a new code object, then a new function object, then
a new method object, then you can call it. Instead of a module of
code, perhaps you could have a datafile containing only these values,
up to twelve per record, one record for each different function you
have.
Here is the benefit:
newcode= dupecode( oldcode, codet1 )
newfun= FunctionType( newcode, {} )
stub.stub= MethodType( newfun, stub )
prev= stub.stub( prev, trans )
print prev
You can loop over these five lines, re-loading function data with
'dupecode', executing it, then reloading the next one, and you have a
different function. Additions to your database of functions would
start in source first (unless you construct each parameter, in
particular co_code, by hand, which you may want), then get compiled,
then go in.
Here is the complete constructor for a code object:
>>> help(_)
Help on code object:
class code(object)
| code(argcount, nlocals, stacksize, flags, codestring, constants,
names,
| varnames, filename, name, firstlineno, lnotab[, freevars[,
cellvars]])
Here's the constructor in Python 3.0:
class code(object)
| code(argcount, kwonlyargcount nlocals, stacksize, flags,
codestring,
| constants, names, varnames, filename, name, firstlineno,
| lnotab[, freevars[, cellvars]])
I defined Stub.stub like this:
class Stub:
def stub( self, prev, trans ):
return prev
stub= Stub( )
You need imports from the types module:
from types import MethodType, FunctionType, CodeType
And here is 'dupecode', which currently only replaces five of the old
function's members with new ones:
def dupecode( old, new ):
newcode= CodeType( old.co_argcount, new.co_nlocals, old.co_stacksize,
old.co_flags,
new.co_code,
new.co_consts, new.co_names,
new.co_varnames, old.co_filename, old.co_name, old.co_firstlineno,
old.co_lnotab )
return newcode
More information about the Python-list
mailing list