Live data from Hacker News

Await Is Not a Context Switch: Understanding Python's Coroutines vs. Tasks

mergify.com

11–20 of 79 posts

Re: Await Is Not a Context Switch: Understanding Python's Coroutines vs. Tasks

#11
I mean of course the post does have a very valid point but it almost repeats like a mantra if there are no asyncio.create_task in your code it’s not concurrent. I mean it should probably at least mention asyncio.gather which IMO would be also much better to explain the examples with

Re: Await Is Not a Context Switch: Understanding Python's Coroutines vs. Tasks

#12
Is this the same as the distinction between a model in which async functions "run synchronously to the first await" vs one in which they "always yield once before executing", as discussed here?

https://www.reddit.com/r/rust/comments/8aaywk/async_await_in...

Re: Await Is Not a Context Switch: Understanding Python's Coroutines vs. Tasks

#14
post #4

Sorry if I've got this wrong, but wouldn't the first example behave the same way in Javascript as well? The function parent() "awaits" the completion of child(), so it wouldn't be possible to interleave the print statements. The example from this StackOverflow question might be a better demonstration: https://stackoverflow.com/q/63455683

You haven't got it wrong, the first example in the article behaves the same in JS, see https://jsfiddle.net/L5w2q1p7/.

Re: Await Is Not a Context Switch: Understanding Python's Coroutines vs. Tasks

#15
post #8

Personally, I've never been able to make async work properly with Python. In Node.js I can schedule enough S3 ListBucket network requests in parallel to use 100% of my CPU core, by just mapping an array of prefixes into an array of ListBucket Promises. I can then do a Promise.all() and let them happen. In Python there's asyncio vs threading, and I feel there's just too much to navigate to quickly get up and running.…

You'd map to asyncio.create_task then asyncio.gather the result to fill your CPU core.

Re: Await Is Not a Context Switch: Understanding Python's Coroutines vs. Tasks

#16

If this await asyncio.sleep(0) doesn't yield control back to an event loop, then what the heck is it actually for?

It does yield control. As far as I know, that's "how you're supposed to it". But the example is not great because there is no other task available to switch to, so the event loop goes right back to where it left off. While the text says otherwise, I'm pretty sure the same thing would happen in JS, C#, and Java.

Re: Await Is Not a Context Switch: Understanding Python's Coroutines vs. Tasks

#17
post #4

Sorry if I've got this wrong, but wouldn't the first example behave the same way in Javascript as well? The function parent() "awaits" the completion of child(), so it wouldn't be possible to interleave the print statements. The example from this StackOverflow question might be a better demonstration: https://stackoverflow.com/q/63455683

The whole article is bit of a mess. Like this thing:

> My mutation block contained no awaits. The only awaits happened before acquiring the lock. Therefore:

> * The critical section was atomic relative to the event loop.

> * No other task could interleave inside the mutation.

> * More locks would not increase safety.

That is exactly the same as with e.g. JS. I'm sure there are lot of subtle differences in how Python does async vs others, but the article fails to illuminate any of it; neither the framing story nor the examples really clarify anything

Re: Await Is Not a Context Switch: Understanding Python's Coroutines vs. Tasks

#18
post #11

I mean of course the post does have a very valid point but it almost repeats like a mantra if there are no asyncio.create_task in your code it’s not concurrent. I mean it should probably at least mention asyncio.gather which IMO would be also much better to explain the examples with

You’re not wrong, but the very first lines of asyncio.gather wrap the supplied arguments with create_task if they’re not already Tasks.
Post reply on HN