PEP 492: isn't the "await" redundant?

[Chris Angelico]

(Did you mean to send this to the list? I hope so; I'm replying to the list.)

On Fri, Aug 26, 2016 at 8:30 PM, Milan Krčmář <milan.krcmar at gmail.com> wrote:
>> Two reasons. One is that Python allows you to call any function and
>> inspect its return value - async functions are no different, and they
>> do return something. The other is that it makes yield points obvious.
>> Consider this hypothetical function:
>
> The return value could be (with proposed syntax) inspected as well.
> The yield point is often visible just from the function you are using:
> async.sleep() vs. sleep() etc.

Not sure how it could be inspected - only the resulting value could.
You couldn't see the Awaitable that gets returned in between.
Depending on the situation, that could be extremely useful.

>> Now, suppose we're trying to figure out what's going on. One good
>> solid technique is what I call "IIDPIO debugging": If In Doubt, Print
>> It Out.
>
> Yes, the 'q = ...; print(q); await q' is a use case to introduce await.
>
>>
>> async def get_user_data(id):
>>     print("Starting g_u_d")
>>     q = db.query("select name from users where id=?", (id,))
>>     print(q)
>>     await q
>
>> "users = Table(...); my_user = await users[123]"
>
> An interesting example. But the 'my_user = await users[123]' must have
> appeared inside 'async def',
> so would be written as 'my_user = users[123]' in "my" syntax...

So what that really means is that, the instant something hits an
awaitable, the entire thread gets paused. That's a perfectly
reasonable way of thinking... if you have a concept of threads that
get explicitly spun off. Otherwise, it's a bit tricky, because there's
no easy way to implement the boundary - the point at which the
awaitable gets added to a queue somewhere (ie the top of the event
loop).

> Chris, thank you for such a long reply. I feel being much more
> reconciled with the "verbose" syntax ;-)

No probs, happy to help out.

ChrisA