[Python-ideas] A send() built-in function to drive coroutines

[Andrew Barnert]

On Feb 23, 2015, at 13:27, Andrew Barnert <abarnert at yahoo.com.dmarc.invalid> wrote:

> On Feb 23, 2015, at 11:10, Luciano Ramalho <luciano at ramalho.org> wrote:
> 
>> On Mon, Feb 23, 2015 at 12:55 PM, Ron Adam <ron3200 at gmail.com> wrote:
>>> When using coroutines, they are generally run by a co-routine framework.
>>> That is how they become "CO"-routines rather than just generators that you
>>> can send values to.  Co-routines generally use the yield to pause/continue
>>> and to communicate to the framework, and not to get and receive data.  In
>>> most case I've seen co-routines look and work very much like functions
>>> except they have yield put in places so they cooperate with the frame work
>>> that is running them.  That frame work handles the starting co-routine.
>>> 
>>> 
>>> I think what you are referring to is generators that are both providers and
>>> consumers, and not co-routines.
>> 
>> Thanks, Ron, this was very helpful, and makes perfect sense to me.
>> 
>> The framework also handles the other feature that distinguishes
>> coroutines from consuming generators: returning values.
>> 
>> In a sense, coroutines are not first-class citizens in Python, only
>> generators are. Coroutines need some supporting framework to be
>> useful.
> 
> No, Python has first-class coroutines. 

I just realized that you _could_ mean something different here, which would be more accurate:

In a few languages, either the execution stack (e.g., most Smalltalks--and most assembly languages, I guess) or continuations 
(e.g., Scheme, SML) are first-class objects, which means first-class coroutines can be written purely within the language. Which means you don't have to write fully-general coroutines, you can use different limited implementations that better fit your current application (e.g., embedding a scheduling discipline under the covers that acts like a trampoline but is invisible in the app code). Python doesn't have that.

But then I'm not sure how your send would be relevant to that meaning, so I still think you mean something like what I said before, based on a misunderstanding of what first-class coroutines can do.

> And coroutines don't need a supporting framework to be useful. For example, a consumer can kick off a producer and the two of them can yield back and forth with no outside help. Or you can compose them into a pipeline, or build a manual state machine, or do all the other usual coroutine things with them.
> 
> But coroutines _do_ need some supporting framework to be useful as general semi-implicit cooperative threads (a la greenlet servers, classic Mac/Windows/wx GUI apps built around WaitNextEvent, non-parallel actor-model designs, etc.). If each coroutine has no idea who's supposed to run next, you need a scheduler framework to keep track of that.
> 
> But because Python has real coroutines, that framework can be written in pure Python. As with asyncio.
> 
>> That's partly what I was trying to address with my `send()`
>> function. I now see the issue is much deeper than I previously
>> thought.
>> 
>> Thanks for the discussion, folks!
>> 
>> Best,
>> 
>> Luciano
>> 
>> 
>> -- 
>> Luciano Ramalho
>> Twitter: @ramalhoorg
>> 
>> Professor em: http://python.pro.br
>> Twitter: @pythonprobr
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/