For a group of tasks, use a nursery.
What do you get? For starters, Ctrl-C/KeyboardInterrupt just works. By restricting the design space, you end up with much more intuitive designs.
Obligatory Structured Concurrency essay link: https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
I recommend giving it a read.
I don’t see much more useful here than understanding the asyncio primitives and available synchronization abstractions, just a different API mostly overlapping the same need
To be clear, trio also has more than one way to wait for a task - any await is the same (e.g. `await trio.sleep(N)` (e.g. `await asyncio.sleep(N)`). I think maybe you’re getting at waiting for a group of tasks?
For a theoretical take see
To be precise, to wait for a task its actually just await. Theres no ensure_future etc. Trio doesn't have the concept of futures or promises at all, and await f() is treated as a single piece of syntax, so in practice it doesn't have "awaitables" either.
I'm not sure it's totally novel though. For instance, C# has AsParallel() extensions which let you run collection operations in parallel (similar functions in Haskell too). It has the same black box behaviour described by the article, and there's an equivalence between direct control flow in code and indirect control flow reified as a data structure, ie. Haskell's case that lazy evaluation and lists are the only control flow construct you need.
Still, it's an interesting imperative incarnation of the idea!
1. the library constantly changed under our feet and that also meant that Stack Overflow articles were all over the place between Python 3.5 and 3.7.
2. I don't think I've ever successfully mocked an async function in python. This made testing async code in python, especially mocking responses from an async web call (an obvious use of async in python) very difficult, if memory serves me. It's been several months since I've used async in python (job change) though, so maybe it's gotten easier or maybe the exact mocking test case issues I had are different drom what I think.
What I realized the other day is that Twisted treats everything like an asyncio Task. That seems to make most of the more confusing gotchas just disappear. I suppose it's a matter of what you're used to though.
Zen of Python is an illusion. Complex things are complex, there’s simply no way to have an interface that’s always clean, useful, and maintainable.
"Beautiful is better than ugly." Requests is more beautiful than urllib2.
"Simple is better than complex." Trio is simpler than asyncio.
"Readability counts." Python is more readable than C++.
"There should be one-- and preferably only one --obvious way to do it." ''.join(strings), not sum(strings, '').
Note what isn't in the Zen of Python: performance, close-to-the-metal-ness, correctness, portability.
Python often fails to live up to its values, but that doesn't make them meaningless.
But even without docs I understood it faster than asyncio and it is more pleasant to use.
Twisted is very elegant, but somehow elegant things get eradicated in the Python world. Time and again.
Don't get me wrong, python is a lovely language when the universe aligns perfectly. But buggy libraries with fragmented interfaces are everywhere in the python community, and any zen that could have been had by pythons expressiveness gets obliterated by the various other warts and faults of the ecosystem. It's just a tool, not a form of enlightenment.
I think the confusion comes about because many people use Tao and zen interchangeably. The Tao is supposed to represent a total understanding of the underlying universal principals, which can be seen as a form of enlightenment.
However Zen is not that.
The zen of python would represent a way to meditate while coding in python. Though I will admit the actual document reads more like a Tao, and it was originally called “the way of Python” (Tao also translates as the way).
- What's a good strategy to migrate a larger python codebase towards asyncio ? (Haven't found any)
use gevent instead