Yeah, we are using different strategies I think. My approach is to not re-run anything that has not changed, so if you change the code of a function in a module

Yeah, we are using different strategies I think. My approach is to not re-run anything that has not changed, so if you change the code of a function in a module, the module's global state will remain untouched, and if you change the code of a decorated function, the decorator will not be re-run (the function inside will be fudged directly). I wouldn't say either approach is intrinsically better, in either case there are situations where it won't do what you want. I think I prefer mine because it is, in a way, a bit more predictable: if e.g. I add a print statement to some function, then the next time I call it, it will print. I know that it won't reset any global state anywhere or re-run anything expensive, regardless of what else there is in the module. Usually, that's what I want. The develoop feature (which I am rewriting right now) sort of does the reloading of currently executing functions, in the sense that you can pick one or more focus functions that are run in a loop and aborted/restarted when the source changes. At some point I looked into changing functions during a breakpoint and continuing in the new code, but I couldn't see any way to do it in pure Python, except maybe through some ctypes voodoo.