[Python-ideas] Cofunctions - an enhancement to yield-from
Guido van Rossum
guido at python.org
Tue Aug 3 16:11:59 CEST 2010
That could be done with a decorator, right? The decorator wraps a
fuction in something non-callable and cocall is a function that
unwraps it and calls it.
On Mon, Aug 2, 2010 at 11:17 PM, Gregory Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> 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
> 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
> Python-ideas mailing list
> Python-ideas at python.org
--Guido van Rossum (python.org/~guido)
More information about the Python-ideas