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

[Arnaud Delobelle]

On 31 October 2011 08:42, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Thinking about how to support cofunctions iterating over
> generators that are themselves cofunctions and therefore
> suspendable, I've come to realise that cofunctionness
> and generatorness really need to be orthogonal concepts.
> As well as functions and cofunctions, we need generators
> and cogenerators.
>
> And thinking about how to allow *that* while building
> on the yield-from mechanism, I found myself inventing
> what amounts to a complete parallel implementation of
> the iterator protocol, in which cogenerators create
> coiterators having a __conext__ method that raises
> CoStopIteration when finished, etc, etc... :-\
>
> At which point I thought, well, why not forget about
> using the iterator protocol as a basis altogether, and
> design a new protocol specifically designed for the
> purpose?
>
> About then I also remembered a thought I had in passing
> earlier, when Nick was talking about the fact that,
> when using yield-from, there is no object available that
> can hold a stack of suspended generators, so you end
> up traversing an ever-lengthening chain of generator
> frames as the call stack gets deeper.
>
> However, with cofunctions there *is* a place where we
> could create such an object -- it could be done by
> costart(). We just need to allow it to be passed to
> the places where it's needed, and with a brand-new
> protocol we have the chance to do that.

Is it worth noting that the implementation in Python (*) that I posted
earlier on does just that?  The costart generator function, when
initiated, keeps track of the stack of suspended generators so that
only the current one is accessed at any time.

-- 
Arnaud

(*) http://www.marooned.org.uk/~arno/cofunctions/cofunctions.py.html