> > > well after all it's a function so the only ways you can get things out > > > of it are: > > > - return a dict with all the objects > > > - use global (very messy) > > > - use a decorator to do either of the above. > > > Messy, all of those... :(. > > > > on the other hand have you consider using a proper test package? > > > instead of inspecting the objects manually from the shell you could > > > make it all automatic. with assert statements. you could use the std. > > > python testing moduleshttp://docs.python.org/lib/development.htmlor > > > something less verbosed like nose > > > Usually, I'm using standard Python testing modules, but sometimes that is > > just an overkill. Sometimes I like to do 'exploratory programming', > > especially in the early phases of development - create a bunch of objects I > > want to play with and do that from IPython. Only way I found out to > > somewhat automate this procedure is to have a function that creates all of > > the test objects, and then raises an exception at the end. IPython starts > > ipdb, so I can work with the objects the function created (without copying > > them back to the shell). But this somehow looks too hack-ish for me, so I > > was wondering if there was an alternative... > > ohhh if that is the case then what you are doing seems to be the > optimal. Just have module lvl code ran the testing in fact I don't > even put those into the if __name__, the reason is that this is just > temp testing that will later become real unit testing, and will never > hit a production app. it gives you the most flexibility.
While you're at it, can you call up prior source, and edit it? BASIC had line numbers: 10 def f( a ): 20 return a+ 1 >>> 15 print( a ) 10 def f( a ): 15 print( a ) 20 return a+ 1 >>> 15 print( a ) 10 def f( a ): 15 print( a ) 20 return a+ 1 '''Interactives could some day have this too:''' >>> edit f Object f opened in editor >>> close Object f written back. Elapsed time 5 minutes. >>> -- http://mail.python.org/mailman/listinfo/python-list
