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

On 12 August 2015 at 07:26, Sven R. Kunze <srku...@mail.de> wrote:
> @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."

Catching up on email after travelling last week, I want to explicitly
note that don't agree with this any more - there's one method name on
the event loop I think needs tweaking (for background blocking calls
in another thread or process), but PEP 492 otherwise delivers all the
pieces needed to make it straightforward to run the event loop as
needed from synchronous code. I did a lightning talk about that at
PyCon Australia, which I'll turn into another
asyncio-in-your-synchronous-test-suite blog post at some point:
https://www.youtube.com/watch?v=_pfJZfdwkgI

Explicitly asynchronous code is as much a tool for thinking as it is
an execution model, so I've come to realise that folks wanting to hide
the conceptual modelling is akin to the complaints we hear from folks
learning imaginary numbers for the first time, and insisting that real
numbers ought to be enough for anyone. Yes, asyncio (like Twisted
before it) does stretch our brains in new and interesting ways -
that's the main reason it's worth having in the standard library :)

Regards,
Nick.

-- 
Nick Coghlan   |   ncog...@gmail.com   |   Brisbane, Australia
_______________________________________________
Python-ideas mailing list
Pyth...@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/