On 31 October 2011 08:42, Greg Ewing firstname.lastname@example.org 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.