3 ms·
> - the coroutine based design means we have a standard api for async, no matter the backend or implementation. Which means solution like trio were able to emer
by ghostwriter 5y ago
> - the coroutine based design means we have a standard api for async, no matter the backend or implementation. Which means solution like trio were able to emerge, and eventually the core dev are now considering including trio-like scoping in the next asyncio iteration.
The structured API for concurrency that Trio provides, in principle, doesn't depend on the said keyword-based approach - it's just what the author chose to use for the implementation. It's definitely not something that asyncio enabled for its users that wasn't possible without it. Here's another structured API for concurrency that doesn't depend on keywords [1]. It can be implemented with gevent.
[1] https://hackage.haskell.org/package/async-2.2.3/docs/Control-Concurrent-Async.html#g:high-45-level-45-utilities https://hackage.haskell.org/package/async-2.2.3/docs/Control...
- BiteCode_dev 5y agoNo, but it does mean that primitives in trio can be awaited in the same way than any async primitive instead of using a callback. I get that scoping trough nurseries is the trio selling point, but you do need to have the ability to run something "before" and "after" a lone async call, and I don't want to have to write a "with" block to wrap any single thing that I wish to await. By having "await" as a universal construct, we allow trio (or anything really) to offer an additional level of granularity - scoping a group of async calls - without losing the smaller one: scoping a single call.