[issue24571] [RFE] Add asyncio.call_async API

Sven R. Kunze added the comment: @David What is the purpose of multitasking code? -- ___ Python tracker ___ ___ Python-bugs-list maili

[issue24571] [RFE] Add asyncio.call_async API

R. David Murray added the comment: "finally a Pythonic (i.e. a single, explicit) way to do squeeze out more of our servers'" I think that you don't understand the purpose of asyncio, then, since squeezing more out of servers is, to my understanding, neither a goal nor something it does (excep

[issue24571] [RFE] Add asyncio.call_async API

Sven R. Kunze added the comment: > I also fear adding too many functions to do the same things. > > For example, scheduling the execution of a coroutine can now be done by: > * asyncio.async(coro) > * asyncio.Task(coro) > * loop.create_task(coro) > * asyncio.ensure_task(coro) If you ask me, th

[issue24571] [RFE] Add asyncio.call_async API

Sven R. Kunze added the comment: > Why bother with asyncio at all? Good question. My initial reaction to async+await was: 'great, finally a Pythonic (i.e. a single, explicit) way to do squeeze out more of our servers'. Moreover, the goal of 'being more like classic code' + 'having reasonable

[issue24571] [RFE] Add asyncio.call_async API

STINNER Victor added the comment: > *If* it needs to be added I like call_in_thread(). Except if you explicitly set the executor to a thread pool executor, the function name can be a lie. It's possible to modify the default executor to a process poll executor. I vote -1 for the function. I wo

[issue24571] [RFE] Add asyncio.call_async API

Guido van Rossum added the comment: But that example also shows what's wrong with the idea. I presume load_remote_data_set1 and load_remote_data_set2 are themselves just using synchronous I/O, and the parallelization is done using threads. So why not use concurrent.futures? Why bother with asy

[issue24571] [RFE] Add asyncio.call_async API

Nick Coghlan added the comment: As a minor note, we didn't use call_in_thread on the event loop because it may be "call_in_process". I've also merged issue 24578 back into this one as Guido suggested. I think the example Sven gave on the mailing list provides a better rationale here than my o

[issue24571] [RFE] Add asyncio.call_async API

Guido van Rossum added the comment: *If* it needs to be added I like call_in_thread(). (We should have used that instead of call_in_executor() on the loop, but too late now.) -- ___ Python tracker

[issue24571] [RFE] Add asyncio.call_async API

Antoine Pitrou added the comment: Oh, and yes, it's not obvious this is needed at all :-) -- ___ Python tracker ___ ___ Python-bugs-li

[issue24571] [RFE] Add asyncio.call_async API

Antoine Pitrou added the comment: FWIW: > The concerns I have with "get_awaitable" are [snip] I agree with you. > I've changed the suggestion function name to "call_async" I disagree. "async" is an extremely overloaded term with no unambiguous meaning (but possible misinterpretations), espec

[issue24571] [RFE] Add asyncio.call_async API

Guido van Rossum added the comment: You seem to miss that run_in_executor() does take *args -- so the partial() call is only needed if you need to pass keyword args. Is it really worth having a helper for this one-liner? def call_async(func, *args): return asyncio.get_event_loop().run_in_e

[issue24571] [RFE] Add asyncio.call_async API

Nick Coghlan added the comment: After trying out some example code in issue 24578, I've changed the suggestion function name to "call_async". The reason is because it makes this kind of code read quite well: futureB = asyncio.call_async(slow_io_bound_operation) futureC = asyncio.call_a