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

@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 <ncog...@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.>

_______________________________________________
Python-ideas mailing list
Pyth...@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/