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

[Greg Ewing]

Ron Adam wrote:
> On Thu, 2011-11-03 at 14:47 +1300, Greg Ewing wrote:
> 
>>However, if something other than 'yield' is used for coroutine
>>suspension -- such as a 'coyield' keyword or coyield() function --
>>then I think this problem becomes solvable. In a cogenerator
>>(i.e. a generator running in coroutine mode), 'coyield' would
>>do what 'yield' does in normal mode (simply suspend the frame),
>>and 'yield(value)' would raise StopIteration(value).
> 
> Well it sounds reasonable,  but how would that actually work?  What if
> the coroutine is paused at coyield, and you need to do a next rather
> than a conext?

That situation shouldn't occur, because if a generator is
suspended at a coyield, it's already in the middle of one
next() call, and you shouldn't be trying to start another
one until the first one is finished.

If you try, you should get an exception, just as happens
now if you try to invoke a generator's next() method
reentrantly:

Python 2.7 (r27:82500, Oct 15 2010, 21:14:33)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> def g():
...  G.next()
...  yield
...
 >>> G = g()
 >>> G.next()
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "<stdin>", line 2, in g
ValueError: generator already executing

> And that is the whole problem... trying to make this all un_coconfusing
> to the average python programmer.  If it's coconfusing to us, they don't
> have a chance.  ;-)

Yes, I'm leaning back towards a completely separate protocol
now. We seem to need a number of new protocol features in
any case, and allowing the two protocols to overlap is just
creating needless confusion, I think.

-- 
Greg