On Aug 7, 2:01 pm, Wilson <[EMAIL PROTECTED]> wrote: > On Aug 6, 6:04 pm, castironpi <[EMAIL PROTECTED]> wrote: > > > > > On Aug 6, 7:24 am, Wilson <[EMAIL PROTECTED]> wrote: > > > > On Aug 4, 9:23 pm, castironpi <[EMAIL PROTECTED]> wrote: > > > > > On Aug 4, 1:57 pm, Wilson <[EMAIL PROTECTED]> wrote: > > > > > > On Aug 4, 6:49 pm, castironpi <[EMAIL PROTECTED]> 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
I see. You want: import states def funa( ): something( ) states.funa= funa And have those changes appear in the actual text of 'states.py'. Are you certain that classes are your best choice for representing states? I am interpreting that you want one class per state, and one method per transition out of that state. How close is that? If you are seeking to generate a .py file from a data structure, why not just edit the data structure directly? If you do need a .py file, can you just regenerate it? -- http://mail.python.org/mailman/listinfo/python-list
