[Python-ideas] Cofunctions PEP - Revision 4

Greg Ewing greg.ewing at canterbury.ac.nz
Thu Aug 12 08:31:52 CEST 2010


ghazel at gmail.com wrote:

> There still has to be some weird way to call cofunctions from regular
> functions. Changing the single definition of a function from "def" to
> "codef" means revisiting all the sites which call that function in the
> body of regular functions, and pushing the change up the stack as you
> mentioned.

Yes, but when using generators as coroutines, I believe
that invoking a coroutine from a non-coroutine will be
a relatively rare thing to do. Essentially you only do
it when starting a new coroutine, and most of the time
it can be hidden inside whatever library you're using
to schedule your coroutines.

In each of my scheduler examples, there is only one
place where this happens. It's not particularly weird,
either -- just a matter of wrapping costart() around
it, which is a normal function, no magic involved.

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

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.

-- 
Greg



More information about the Python-ideas mailing list