[Python-ideas] Cofunctions - an enhancement to yield-from

Gregory Ewing greg.ewing at canterbury.ac.nz
Tue Aug 3 08:17:30 CEST 2010

On 03/08/10 04:39, Guido van Rossum wrote:
> inevitably my coding went something like (1) forget to put
> a yield in, (2) frantically debug, (3) slap forehead, (4) add "if 0:
> yield" to the function, (5) continue with another instance of this,
> (6) lose sleep over the best place to spell the dummy yield and where
> to put it. At the same time I don't want to have to mark all my
> coroutines with a decorator, like Monocle requires (though maybe I
> should).

Would you be interested in a system which requires marking
calls to coroutines, but tells you immediately when you
have forgotten to mark such a call?

It might work something like this:

1. In a cofunction, a call to another cofunction must
    be marked with 'cocall', e,g.

    z = cocall f(x, y)

2. Cofunctions *cannot* be called normally -- they do
    not have a __call__ method, only a __cocall__ method.

So if you try to call a cofunction without using cocall,
you get an exception. If you try to call an ordinary function
using cocall, you get an exception. If you try to use cocall
but forget to declare the function with codef, you get an
exception (because cocall would only be allowed inside a

To start things off, a builtin function could be provided
such as

   def costart(f, *args, **kwds):
     return f.__cocall__(*args, **kwds)

which would return an object that a coroutine driver could
treat as a generator.

I think this scheme would go a long way towards satisfying
Antoine's desire to conceptually separate generators and
coroutines. It would also enable an implementation to
implement coroutines using a different mechanism from
generators if it wanted to.


This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more

More information about the Python-ideas mailing list