On 11 July 2015 at 20:17, Nick Coghlan <ncoghlan@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. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia