There's been some chatter on edu-sig (python.org) of late regarding Python's capabilities in the "edit/continue" tradition, meaning debugging tools, and/or IDE tools, that give the developer real time write access to running programs.
I think a good design would be something like the ZODB, or the ZODB itself, to save the entire working environment, like a Smalltalk image, at which point a "supervisor Python" (a whole different instance, perhaps on another chip), could do "brain surgery" on the "hibernating Python" (like a patient undergoing surgery). You basically simulate or emulate the "operating table" version, without putting yourself at its mercy. If you break it completely, while doing your brain surgery, just abort the instance and roll back to the previously saved version. It's like sitting on top of a version control system, while never getting to directly edit the currently operating version (the supervisor). The alternative, allowing a developer to undermine his/her own running platform, seems to unnecessarily conflate a runtime and design time mode, which isn't just some stupid prejudice. We need that separation, just as we keep distance between production and development copies of things. Don't fix a running engine if you can fix an emulated running engine. Once you're happy with your changes, commit, and set it running for real. It still might crash, which is why you're glad for rollback capabilities. Smalltalk images meet CVS? Python atop Mercurial? Kirby -- http://mail.python.org/mailman/listinfo/python-list
