[Python-ideas] Cofunctions PEP - Revision 4

Guido van Rossum guido at python.org
Thu Aug 12 16:38:35 CEST 2010

On Wed, Aug 11, 2010 at 11:31 PM, Greg Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> ghazel at gmail.com wrote:
>> Again, marking the points at which your function could be suspended is
>> a very important feature, in my mind.
> I'm still very far from convinced about that. Or at least
> I'm not convinced that the benefits of such awareness
> justify the maintenance cost of keeping the call markers
> up to date in the face of program changes.
> Also, consider that if cocall is made to work on both
> ordinary functions and cofunctions, there is nothing to
> stop you from simply marking *every* call with cocall
> just on the offchance. People being basically lazy, I
> can well imagine someone doing this, and then they've
> lost any suspendability-awareness benefit that the
> call markers might bring.
> Even if they don't go to that extreme, there is nothing
> to ensure that cocall markers are removed when no longer
> necessary, so redundant cocalls are likely to accumulate
> over time, to give misleading indications to future
> maintainers.

I'm with ghazel on this one. Long, long ago I used a system that
effectively used implicit cocalls. It was a threading OS with
non-preemptive scheduling, so instead of locking you'd just refrain
from calling any one of the (very few) syscalls that would allow
another thread to run. This worked fine when we just got started, but
as we started building more powerful abstractions, a common bug was
making a call to some abstraction which behind your back, sometimes,
perhaps inside more abstraction, would make a syscall. This was
nightmarish to debug (especially since it could happen that the
offending abstraction was maintained by someone else and had just
evolved to make its first syscall).

So, coming back to this, I think I am on the side of explicitly
marking cocalls. But whether it's better to use cocall or yield-from,
I don't know.

--Guido van Rossum (python.org/~guido)

More information about the Python-ideas mailing list