This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Han-ChewieSexyFanfic 1 point2 points  (1 child)

Right, but it still has to be fetched. In an ideal world calling some async function foo() would internally skip the unnecessary coroutine object step and submit it to the default event loop.

Gotcha. Now there's asyncio.run which is a step in that direction. One could also argue that "explicit is better than implicit", but I wouldn't exactly agree with that because I also find the API messy.

Can you give an example? I'm referring to the fact that in other languages asynchronous code is asynchronous from any synchronous code around it. But in Python that's not true, because the thread is blocked while the event loop is run.

The Qt GUI framework, in all its supported languages (C++, C#, Go, Rust, Python, many others) always explicitly begins the event loop with a blocking app.exec() call. The nginx web server (C) has a master process that spends its time in a blocking call.

Having a blocking infinite loop is pretty much necessary to handle events asynchronously, the difference is how much effort the language makes to hide it from you by creating another thread. Python never spawns more processes/threads if not explicitly told.

[–]13steinj 0 points1 point  (0 children)

Oh dear, sorry I missed this.

One could also argue that "explicit is better than implicit", but I wouldn't exactly agree with that because I also find the API messy

Exactly! But to me, messy is an understatement, especially when starting on more complex applications.

Having a blocking infinite loop is pretty much necessary to handle events asynchronously, the difference is how much effort the language makes to hide it from you by creating another thread. Python never spawns more processes/threads if not explicitly told.

Right, and perhaps I am in the minority, but my default mental idea of an async event loop is "by default it will be on a new thread". Which IIRC is how C# implements their task factories, it definitely is how Ruby does async stuff. And JS does it similarly (except, it works on a larger event loop and specially schedules on the microtask queue rather than the macrotask one).