<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>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.</div><div><br></div><div>I feel like having the await syntax trigger by default on any awaitable invocation in a coroutine context makes much more sense. I consider async/await syntax to be too complicated for the average developer since it opens up too many abilities whereas most developers would always mean they prefer to do this:</div><div><br></div><div>result = [await fun(x) for fun in funcs]<br></div><div><br></div><div>versus:</div><div><br></div><div>result = [fun(x) for fun in funcs]  <br></div><div dir="ltr">await asyncio.gather(*result)<br></div><div dir="ltr"><br></div><div>Moreso, having it become the default makes statements like this:</div><div><br></div><div><div>result = [await fun(x) for fun in <span class="gmail-gr_ gmail-gr_210 gmail-gr-alert gmail-gr_spell gmail-gr_inline_cards gmail-gr_run_anim gmail-ContextualSpelling" id="gmail-210" style="display:inline;border-bottom:2px solid transparent;background-repeat:no-repeat;color:inherit;font-size:inherit">funcs</span> if await smth]<br></div><br class="gmail-Apple-interchange-newline"></div><div>Look like this:</div><div><div><br></div><div>result = [fun(x) for fun in <span class="gmail-gr_ gmail-gr_210 gmail-gr-alert gmail-gr_spell gmail-gr_inline_cards gmail-gr_run_anim gmail-ContextualSpelling" id="gmail-210" style="display:inline;border-bottom:2px solid transparent;background-repeat:no-repeat;color:inherit;font-size:inherit">funcs</span> if smth]<br></div></div><div><br></div><div>Therefore, my suggestion is to create a new "async" definition which basically turns every function invocation into an "await" if a generator is returned. Instead of "async def" I propose the alternative "coroutine def" syntax. However, a better solution may be to imply the word "async" in every function definition given some sort of trigger (however I assume that this won't be the preferable approach as it is not something that can be implemented at the parsing level).</div><div dir="ltr"><br></div><div>For me, I believe that Python should aspire to be both concise and straightforward, which means no boilerplate code just because it's more "correct" but rather assume there's some logical default behavior going on in the back - and to me this logical behavior is that every invocation can trigger an await and go back to the main loop. Our assumption that a function invocation has to tie back to instant execution unless an "await" statement has been placed should be challenged in favor of readability, conciseness, and to always aim to appeal to novice developers (which I believe is the reason Python is on such a rise these days).</div><div dir="ltr"><br></div><div>I do have to admit I have not thought through what is the best syntax or the implications of this because I would like to see what is the general opinion on this idea first.</div><br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="margin:0px 0px 8px"><p style="margin:0px"><font size="2"><span style="font-family:arial,helvetica,sans-serif">- Ron</span></font></p></div></div></div></div></div></div></div></div></div></div>