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.
... 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.