[Python-ideas] Cofunctions - Getting away from the iterator protocol

Nick Coghlan ncoghlan at gmail.com
Tue Nov 1 02:14:44 CET 2011


On Tue, Nov 1, 2011 at 10:22 AM, Ron Adam <ron3200 at gmail.com> wrote:
> 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 at gmail.com   |   Brisbane, Australia



More information about the Python-ideas mailing list