Limits of Metaprogramming
castironpi at gmail.com
Wed Aug 6 19:04:51 CEST 2008
On Aug 6, 7:24 am, Wilson <PaulAlexWil... at gmail.com> wrote:
> On Aug 4, 9:23 pm, castironpi <castiro... at gmail.com> wrote:
> > 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.
> Still don't really understand this so I'm going to admit defeat.
> Thanks all for your advice... Very much appreciated!
I was describing an alternative to storing functions in a way that
wasn't in serial in plain text. It was off-topic from state-machine
Can you start with this?
# state, input, next state
( 0, 'a', 1 ),
( 1, 'a', 2 ),
( 2, 'a', 0 ),
( 0, 'b', 0 ),
( 1, 'b', 0 ),
( 2, 'b', 2 )
More information about the Python-list