Limits of Metaprogramming

[castironpi]

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
transitions.

Can you start with this?

# state, input, next state
transitions= [
  ( 0, 'a', 1 ),
  ( 1, 'a', 2 ),
  ( 2, 'a', 0 ),
  ( 0, 'b', 0 ),
  ( 1, 'b', 0 ),
  ( 2, 'b', 2 )
]

What further?