Guido> What kind of limitations do other systems that support modifying
Guido> a "live" program being debugged impose? Only allowing
Guido> modification of the function at the top of the stack might
Guido> eliminate some problems, although there are still ways to mess
Guido> up.
Frame objects maintain pointers to the active code objects, locals and
globals, so modifying a function object's code or globals shouldn't have any
effect on currently executing frames, right? I assume frame objects do the
usual INCREF/DECREF dance, so the old code object won't get deleted before
the frame object is tossed.
Guido> But what would it do when we changed a global variable? Say a
Guido> module originally contains a statement "x = 0". Now we change
Guido> the source code to say "x = 100". Should we change the variable
Guido> x? Suppose that x is modified by some of the computations in the
Guido> module, and the that, after some computations, the actual value
Guido> of x was 50. Should the "recompile" reset x to 100 or leave it
Guido> alone?
I think you should note the change for users and give them some way to
easily pick between old initial value, new initial value or current value.
Guido> Please, no more posts about Scheme. Each new post mentioning
Guido> call/cc makes it *less* likely that something like that will ever
Guido> be part of Python. "What if Guido's brain exploded?" :-)
I agree. I see call/cc or set! and my eyes just glaze over...
Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com | Musi-Cal: http://www.musi-cal.com/
518-372-5583
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4