Couldn't you do almost the exact same thing using pdb, without all the C API / register stuff?
Maybe I misunderstood the post, but it sounds like you're just stopping right before the request returns, reloading the module, generating a new response, and allowing execution to continue.
You're right! You could do all of this with pdb, but only if you have enough foresight to run the app under pdb to begin with (which I definitely never do).
Using GDB, you don't have to change the app or remember to run it in a particular way.
Right, I see the use in this now. How difficult would it be to wrap this up in a reusable script that you could run directly, instead of having to manually work through the debugger prompt?
I've done this manually a few times, but with foresight attaching signal handlers that open up a port or dump stack (a la `jstack`) is usually less finicky.
Normally, the "finish" command will interrupt any script you're in the middle of executing, so we have to do a bit of an ugly hack to make sure our script keeps running:
b PyEval_EvalFrameEx if strcmp(PyString_AsString(f->f_code->co_name), "handle_uncaught_exception") == 0
(Bah. Edited because I couldn't get monospace text working)
You could put those commands into a file and run "gdb -p <my django process> -x <my commands file>"
Of course, instead of shelling out to git stash pop, you'd probably want to pause so you could update the code. And you may need to reload more modules than just monospace.views and monospace.urls, depending on the change.
Maybe I misunderstood the post, but it sounds like you're just stopping right before the request returns, reloading the module, generating a new response, and allowing execution to continue.
Why is GDB required for any of this?