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.rei...@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 <ros...@gmail.com> wrote: > >> On Tue, Oct 30, 2018 at 6:01 PM Ron Reiter <ron.rei...@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@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
