[Python-ideas] A send() built-in function to drive coroutines
Andrew Barnert
abarnert at yahoo.com
Mon Feb 23 22:27:07 CET 2015
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.
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/
More information about the Python-ideas
mailing list