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 wrote:
> You are right that
On Tue, Oct 30, 2018 at 11:36 PM Ron Reiter 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"
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
On Tue, Oct 30, 2018 at 6:01 PM Ron Reiter 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
Ron Reiter wrote:
I feel like having the await syntax trigger by default on any awaitable
invocation in a coroutine context makes much more sense.
Guido seems to regard the requirement to use 'await' as a
feature, not a bug. He says he likes to be able to see where
all the potential suspension
One of Golang's advantages is that goroutines act like gevent's coroutines
instead of relying on an async/await syntax. In my opinion, it makes Golang
code much more readable.
I feel like having the await syntax trigger by default on any awaitable
invocation in a coroutine context makes much more
