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

[Guido van Rossum]

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
>> 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
> cofunction).
>
> 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.
>
> --
> Greg
>
> 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
> information.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



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