Steve, thanks for the response, and yes, I've experimented with reverse debugging, and yes for the reasons specified in that article you gave it isn't really practical with anything but small projects because of the massive amounts of memory usage. But that's really not what I'm asking for here. I'm simply asking that python give developers the opportunity to stop execution and open up a debugger *before* the exception is hit, and be able to instrument the code at that point using that debugger. The way that I mimic this in perl is by wrapping places where die, confess, croak, AUTOLOAD, etc are hit with something that looks like this: sub _confess { $DB::single = 1; my $trap = 1; if ($trap) { confess(@_); } } that way, I can short-circuit evals before they happen and save the state to both examine and modify. It's a hack, but it's a manageable hack since there are only so many places where things can go off the rails in perl, and I cover each exit. I can set $trap = 0 and lo-and-behold it will continue as if no trap was issued. Now, if there is global reverse debugging implemented in python, this has got to be doable as well. I'd dare say it could be done with very little overhead in memory.

You know you can set breakpoints in the debugger? You don't have to single-step all the way through from the beginning. It isn't clear from your post how experienced you are.

ok just to be on the totally clear side, yes I'm quite aware of pdb.set_trace(), etc. They however don't do much to help the pain of debugging and maintaining code which is *not your own*. For all good they are, you might as well step through each line because you have no clue where the mines in a particular script or library reside, and when you are going to hit them. And of course depending on how good the debugging implementation is, when you hit these mines they may be well-nigh impossible to remove without something like this. Which btw is the main reason WHY I'm asking for this, and this is why I think it would be such a productivity booster. Not for my code which I control, but for others. I'll take one particular experience here to make my point. I've been experimenting with an automation framework written in python here that shall otherwise remain nameless (except it is a fairly popular one). Its ssh layer is *notoriously* obtuse, it freezes up on multiple occasions,the support lists are clogged with issues surrounding it, yet release-after-release things don't get fixed. Why? I'd argue because the code is hard to parse but even harder to debug. Having something like this would be a great boon to fixing any such issues. So that's basically it. No - I'm not looking for a full-blown reverse debugger for the reasons you state. I'm looking for something more limited and therefore more workable. Ed