Limits of Metaprogramming

[Wilson]

On Aug 6, 6:04 pm, castironpi <castiro... at gmail.com> wrote:
> 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?

My problem relates to the states really. I'd like to import a file
containing the state classes into a "state editor" that is just a
class editor really. Then, at *runtime* I'd like to add and remove
methods from this class and change its attributes (__dict__). I'd also
like to be able to add and remove classes from the module. When done,
I was hoping to do introspection upon which classes were associated
with this module and write back the modified class definitions to the
same module. Next time the module is imported, the changes would
remain intact. Unfortunately, inspect.getsource() reads the original
file and does not magically return source from the runtime objects.

Hope that makes sense!
Paul