[Python-ideas] gevent-like Coroutines in Python

[Mark E. Haase]

Python's coroutines are designed to make suspension points visible, which
enhances "local reasoning" about code. This concept has been written up
very well over here: https://glyph.twistedmatrix.com/2014/02/unyielding.html

On Tue, Oct 30, 2018 at 8:37 AM Ron Reiter <ron.reiter at gmail.com> wrote:

> You are right that they are different, I was actually assuming that
> developers by default don't try to parallelize and would rather go ahead
> and write code to yield one function at a time, which is fine. The need to
> separate "await" from the invocation is something which is rarely used. Not
> sure what you mean about "threading" as it is still more efficient and
> lightweight to parallelize workers on an event loop rather than using
> blocking threads.
>
> As I said - I don't think we should downgrade Python's current ability to
> do so, my suggestion is to create something like the "codef" proposal,
> which will also await on every function invocation - for readability.
>
> - Ron
>
>
> [image: Facebook] <http://www.facebook.com/ron.reiter> [image: Twitter]
> <http://twitter.com/#!/ronreiter> [image: LinkedIn]
> <https://il.linkedin.com/in/ronreiter>
>
>
> On Tue, Oct 30, 2018 at 12:41 PM Chris Angelico <rosuav at gmail.com> wrote:
>
>> On Tue, Oct 30, 2018 at 6:01 PM Ron Reiter <ron.reiter at gmail.com> wrote:
>> >
>> > ... most developers would always mean they prefer to do this:
>> >
>> > result = [await fun(x) for fun in funcs]
>> >
>> > versus:
>> >
>> > result = [fun(x) for fun in funcs]
>> > await asyncio.gather(*result)
>> >
>> > Moreso, having it become the default makes statements like this:
>> >
>> > result = [await fun(x) for fun in funcs if await smth]
>> >
>> > Look like this:
>> >
>> > result = [fun(x) for fun in funcs if smth]
>> >
>> > Therefore, my suggestion is to create a new "async" definition which
>> basically turns every function invocation into an "await" if a generator is
>> returned.
>> >
>>
>> I'm not sure what you're driving at here. From your first example, I
>> gather that (pun intended) you're expecting the 'result' list to
>> contain all the results from the different function calls, running
>> them all in parallel; but your second example and described suggestion
>> seem to imply that the waitings would continue to be sequential.
>>
>> Unless you're asking for straight-up magic ("do everything in parallel
>> unless they need to be serialized"), there still needs to be a clear
>> way to differentiate between "wait for this right now and give me a
>> result before this function continues" and "gather all these jobs
>> together, get me the results, and then move on once you have them
>> all". It might perhaps be nice to have an easier/more obvious syntax
>> for gather(), but it definitely needs to have some form of spelling.
>>
>> If you're not asking for them to be run in parallel, you're asking for
>> an implicit way for a function call to block its caller, and for the
>> calling function to act sequentially. Python already has that - it's
>> called threading :)
>>
>> ChrisA
>> _______________________________________________
>> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20181030/7d47baeb/attachment-0001.html>