On Tue, Nov 1, 2011 at 10:22 AM, Ron Adam
On Tue, 2011-11-01 at 10:06 +1300, Greg Ewing wrote:
Ron Adam wrote:
If we put some strict requirements on the idea.
1. Only have a *SINGLE* exception type as being resumable.
2. That exception should *NEVER* occur naturally.
3. Only allow continuing after it's *EXPLICITLY RAISED* by a raised statement.
All of the problem issues go away with those requirements in place, and you only have the issue of how to actually write the patch. Earlier discussions indicated, it might not be that hard to do.
I'm not familiar with these earlier discussions. Did they go as far as sketching a feasible implementation? It's all very well to propose things like this, but the devil is very much in the details.
Yeah, there isn't very much about the details, but I think it is worth looking into as it would pretty much does exactly what is needed. (IMHO)
It gave me another thought on an existing utility worth exploring in this context: pdb's post-mortem capabilities. Now, those *don't* implement coroutines (when you do a postmortem, you end up in an emulation of the eval loop, not the eval loop itself). However, that exception instance *does* contain the full frame stack, all the way down to where the exception was thrown. Figuring out what hooks you would need in the core eval loop in order to reinstate an exception's frame stack as the "real" frame stack might be an interesting exercise. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia