[Python-ideas] Learning from the shell in supporting asyncio background calls

[Sven R. Kunze]

@Nick

It seems like, we are not alone in our thinking that asyncio still needs 
many more convenience wrappers.

https://mail.python.org/pipermail/python-list/2015-August/694859.html

Same conclusion as yours and mine:

"I think python's non blocking I/O is far from being something useful 
for developers till non-async code can invoke async code transparently. 
Duplicating all code/libs when you realize that something not fits 
asyncio is not a solution and even less a pythonic solution."


On 12.07.2015 04:48, Nick Coghlan wrote:
> On 11 July 2015 at 20:17, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> I'll sleep on that, and if I still like that structure in the morning,
>> I'll look at revising my coroutine posts.
> I've revised both of my asyncio posts to use this three part helper
> API to work with coroutines and the event loop from the interactive
> prompt:
>
> * run_in_foreground
> * schedule_coroutine
> * call_in_background
>
> I think the revised TCP echo client and server post is the better of
> the two descriptions, since it uses actual network IO operations as
> its underlying example, rather than toy background timers:
> http://www.curiousefficiency.org/posts/2015/07/asyncio-tcp-echo-server.html
>
> As with most of the main asyncio API, "run" in this revised setup now
> refers specifically to running the event loop. ("run_in_executor" is
> still an anomaly, which I now believe might have been better named
> "call_in_executor" to align with the call_soon, call_soon_threadsafe
> and call_later callback management APIs, rather than the run_* event
> loop invocation APIs)
>
> The foreground/background split is now intended to refer primarily to
> "main thread in the main process" (e.g. the interactive prompt, the
> GUI thread in a desktop application, the main server process in a
> network application) vs "worker threads and processes" (whether
> managed by the default executor, or another executor passed in
> specifically to "call_in_background"). This is much closer in spirit
> to the shell meaning.
>
> The connection that "call_in_background" has to asyncio over using
> concurrent.futures directly is that, just like schedule_coroutine,
> it's designed to be used in tandem with run_in_foreground (either
> standalone, or in combination with asyncio.wait, or asyncio.wait_for)
> to determine if the results are available yet.
>
> Both schedule_coroutine and call_in_background are deliberately
> restricted in the kinds of objects they accept - unlike ensure_future,
> schedule_coroutine will complain if given an existing future, while
> call_in_background will complain immediately if given something that
> isn't some kind of callable.
>
> Regards,
> Nick.
>