[Python-ideas] Possible PEP 380 tweak (original) (raw)

Jacob Holm jh at improva.dk
Fri Oct 29 02:45:00 CEST 2010

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.

More information about the Python-ideas mailing list