Honestly, I don't understand the issue. (Or maybe I'm too tired right now.) But I think asyncio is actually very well designed. We just have to keep in mind that code is either synchronous or asynchronous. Code that consumes too much CPU or does blocking calls does definitely not belong in an event driven system. By the way, the shell equivalent of "&" is definitely a thread, not a coroutine. And "fg" (foreground) equals "thread.join". You were also talking about a Repl. Not sure if this helps, but "ptpython", the REPL that I develop can be embedded into any application as a coroutine. There is no blocking I/O in the Repl. https://github.com/jonathanslenders/ptpython/blob/master/examples/asyncio-py... @nick: About the discussion you are referring to. For solving the producer/consumer problem, the answer is probably to use asyncio Queues (Have a look at the put and get method.) Jonathan 2015-08-11 23:26 GMT+02:00 Sven R. Kunze <srkunze@mail.de>:
@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@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 Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/