On 12 August 2015 at 07:26, Sven R. Kunze <srkunze@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 | ncoghlan@gmail.com | Brisbane, Australia