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

Andrew Barnert abarnert at yahoo.com
Mon Feb 23 22:40:41 CET 2015

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/

More information about the Python-ideas mailing list