Generally, I think we could make something very useful even with a number of limitations. For example, I would find a first cut completely acceptable and a great improvement on today if:
* Only the function at the top of the stack can be recompiled and have the code reflected while executing. This function also must be restarted after such an edit. If the function uses global variables or makes calls that restarting will screw-up, then either a) make the code changes _before_ doing this stuff, or b) live with it for now, and help us remove the limitation :-)
OK, restarting the function seems a reasonable compromise and would seem relatively easy to implement. Not *real* easy though: it turns out that eval_code2() is called with a code object as argument, and it's not entirely trivial to figure out the corresponding function object from which to grab the new code object. But it could be done -- give it a try. (Don't wait for me, I'm ducking for cover until at least mid June.)
Ironically, I turn this feature _off_ for Python extensions. Although changing the C code is great, in 99% of the cases I also need to change some .py code, and as existing instances are affected I need to restart the app anyway - so I may as well do a normal build at that time. ie, C now lets me debug incrementally, but a far more dynamic language prevents this feature being useful ;-)
I hear you.
If we forced a restart would this be better? Can we reliably reset the stack to the start of the current function?
Yes, no problem.
If this would work for the few changed functions/methods, what would the impact be of doing it for _every_ function (changed or not)? Then the analysis can drop to the module level which is much easier. I dont think a slight performace hit is a problem at all when doing this stuff.
Yes, this would be fine too.
"What if Guido's brain exploded?" :-)
At least on that particular topic I didnt even consider I was the only one in fear of that! But it is good to know that you specifically are too :-)
Have no fear. I've learned to say no. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)