[Python-ideas] Cofunctions PEP - Revision 4

[ghazel at gmail.com]

On Wed, Aug 11, 2010 at 11:31 PM, Greg Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> ghazel at gmail.com wrote:
>
>> I think this is the wrong direction. But, if you want to head that
>> way, why not make calling a cofunction from a function also
>> transparent, and exhaust the iterator when the function is called?
>
> Because this is almost always the *wrong* thing to do.
> The cofunction you're calling is expecting to be able to
> suspend the whole stack of calls right back up to the
> trampoline, and by automatically exhausting it you're
> preventing it from being able to do so.

Right, this is also why you do not always join a thread immediately
after launching it. So if cofunctions have a special way of launching
and are preemptable at unmarked points and terminate at some time in
the future which is based on an indeterminate number of iterations,
why not just use threads? codef could simply be a decorator something
like this:

def codef(f):
    t = threading.Thread(target=f)
    t.start()
    while t.is_alive():
        t.join(0.010)
        yield


> Calling a cofunction from a non-cofunction is overwhelmingly
> likely to be an error, and should be reported as such.
> For cases where you really do want to exhaust it, a function
> could be provided for that purpose, but you should have
> to make a conscious decision to use it.
>
>> 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.

The important thing about a cooperation point is that you are
specifying where it is safe to pause your function - even if it is not
paused. The accumulation of these could eventually be noisy, but it is
safe. If someone decorates all their calls with cocall, they have just
written a bunch of bugs, and it was hard to do that. Automatically
adding cocall everywhere creates a bunch of bugs which they are
unaware of.

-Greg