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

[Jonathan Slenders]

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-python-embed.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 at 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 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.
>>
>>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150812/eb480eff/attachment.html>