[Python-ideas] Possible PEP 380 tweak

[Jacob Holm]

On 2010-10-28 22:14, Greg Ewing wrote:
> Jacob Holm wrote:
> 
>> 1) Define a new "coiterator" protocol, consisting of a new special
>> method __conext__, and a new StopCoIteration exception that the regular
>> StopIteration inherits from.
> 
> I don't think it's necessary to have a new protocol. All
> that's needed is to allow for the possibility of the
> __next__ method of an iterator being a cofunction.
> 

That is more or less exactly what I did for my second version.  Turns
out to be less simple than that because you need to "next" work as a
cofunction as well, and there is a problem with raising StopIteration
from a cofunction.


> Under the current version of PEP 3152, with an explicit
> "cocall" operation, this would require a new kind of
> for-loop. Maybe using "cofor"?
> 
> However, my current thinking on cofunctions is that
> cocalls should be implicit -- you declare a cofunction
> with "codef", and any call made within it can potentially
> be a cocall. In that case, there would be no need for new
> syntax -- the existing for-loop could just do the right
> thing when given an object whose __next__ method is a
> cofunction.
> 
> Thinking about this has made me even more sure that
> implicit cocalls are the way to go, because it means
> that any other things we think of that need to take
> cofunctions into account can be fixed without having
> to introduce new syntax for each one.
> 

Yes.  Looking at a few examples using my toy implementation of Go
channels made me realise just how awkward it would be to have to mark
all cocall sites explicitly.

With implicit cocalls and a for-loop changed to work with a cofunction
__next__, working with channels can be made to look exactly like working
with generators.  For me, that would be a major selling point for the PEP.

- Jacob