3 ms·

If you are ever considering making use of asyncio for your project, I would strongly recommend taking a look at curio [1] as an alternative. It's like asyncio b

If you are ever considering making use of asyncio for your project, I would strongly recommend taking a look at curio [1] as an alternative. It's like asyncio but far, far easier to use. [1] https://curio.readthedocs.io/en/latest/index.html https://curio.readthedocs.io/en/latest/index.html

acidbaseextract 5y ago
The video (or blog post) below is one of the best explanations I've seen about what subtle bugs are easy to make with asyncio, why it's easy to make them, and how the trio library addresses them. But yes, consider alternatives before you pick asyncio as your approach! Talk: https://www.youtube.com/watch?v=oLkfnc_UMcE https://www.youtube.com/watch?v=oLkfnc_UMcE Blog post: https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
VWWHFSfQ 5y ago
Highly recommend curio
deleted 5y ago
[deleted]
BiteCode_dev 5y ago
While the design of Curio is quite interesting, it's may not be a good choice, not for technical reasons, but for logistical reasons: the chances it gets a wide adoption are slim to None. And since we are stuck with colored functions in python, the choice of stack matters very much. Now, if you want easier concurrency, and a solution to a lot of concurrency problems that curio solves, while still being compatible with asyncio, use anyio: https://anyio.readthedocs.io/en/stable/ https://anyio.readthedocs.io/en/stable/ It's a layer that works on top of asyncio, so it's compatible with all of it. But it features the nursery concept from Trio, which makes async programming so much simpler and safer.
- heavyset_go 5y ago
  anyio is also compatible with asyncio and Trio, so you can use it with either library or paradigm.
  - sandGorgon 5y ago
    Uvloop/uvicorn - which is the production grade asgi server only works with asyncio. Hypercorn works with trio..but you lose a LOT of performance
quietbritishjim 5y ago
Curio's spiritual successor is Trio [1], which was written by one of the main Curio contributors and is more actively maintained (and, at this point, much more widely used). Like Curio, it's much easier to use than asyncio, although ideas from it are gradually being incorporated back into asyncio e.g. asyncio.run() was inspired by curio.run()/trio.run(). I have used Trio in real projects and I thoroughly recommend it. This blog post [2] by the creator of Trio explains some of the benefits of those libraries in a very readable way. [1] https://trio.readthedocs.io/en/stable/ https://trio.readthedocs.io/en/stable/ [2] https://vorpus.org/blog/some-thoughts-on-asynchronous-api-design-in-a-post-asyncawait-world/ https://vorpus.org/blog/some-thoughts-on-asynchronous-api-de...
- miohtama 5y ago
  This is super interesting. How does async approaches work across different Python libraries? Are there any assumptions about usage of asyncio?
  - nerdponx 5y ago
    The "async/await" syntax is agnostic of the underlying async library, but Asyncio and Trio provide incompatible async "primitives". So yes, you need to write your code for one or the other, or use Anyio, which is a common layer over both. Many more libraries use Asyncio than Trio, so I have come to recommend Anyio (which has a Trio-like API) but with Asyncio as the backend. That gives you the extensive Asyncio ecosystem but with the structured concurrency design of Trio.
- nerdponx 5y ago
  As yet another option, I really like Anyio, which is a "frontend" to either Asyncio or Trio, which provides a consistent and tidy API for what is known as "structured concurrency" (I think the name was popularized by the C library Dill). https://anyio.readthedocs.io https://anyio.readthedocs.io

acidbaseextract 5y ago

The video (or blog post) below is one of the best explanations I've seen about what subtle bugs are easy to make with asyncio, why it's easy to make them, and how the trio library addresses them. But yes, consider alternatives before you pick asyncio as your approach! Talk: https://www.youtube.com/watch?v=oLkfnc_UMcE https://www.youtube.com/watch?v=oLkfnc_UMcE Blog post: https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

VWWHFSfQ 5y ago

Highly recommend curio

deleted 5y ago

[deleted]

BiteCode_dev 5y ago

While the design of Curio is quite interesting, it's may not be a good choice, not for technical reasons, but for logistical reasons: the chances it gets a wide adoption are slim to None. And since we are stuck with colored functions in python, the choice of stack matters very much. Now, if you want easier concurrency, and a solution to a lot of concurrency problems that curio solves, while still being compatible with asyncio, use anyio: https://anyio.readthedocs.io/en/stable/ https://anyio.readthedocs.io/en/stable/ It's a layer that works on top of asyncio, so it's compatible with all of it. But it features the nursery concept from Trio, which makes async programming so much simpler and safer.

heavyset_go 5y ago
anyio is also compatible with asyncio and Trio, so you can use it with either library or paradigm.
- sandGorgon 5y ago
  Uvloop/uvicorn - which is the production grade asgi server only works with asyncio. Hypercorn works with trio..but you lose a LOT of performance

quietbritishjim 5y ago

Curio's spiritual successor is Trio [1], which was written by one of the main Curio contributors and is more actively maintained (and, at this point, much more widely used). Like Curio, it's much easier to use than asyncio, although ideas from it are gradually being incorporated back into asyncio e.g. asyncio.run() was inspired by curio.run()/trio.run(). I have used Trio in real projects and I thoroughly recommend it. This blog post [2] by the creator of Trio explains some of the benefits of those libraries in a very readable way. [1] https://trio.readthedocs.io/en/stable/ https://trio.readthedocs.io/en/stable/ [2] https://vorpus.org/blog/some-thoughts-on-asynchronous-api-design-in-a-post-asyncawait-world/ https://vorpus.org/blog/some-thoughts-on-asynchronous-api-de...

miohtama 5y ago
This is super interesting. How does async approaches work across different Python libraries? Are there any assumptions about usage of asyncio?
- nerdponx 5y ago
  The "async/await" syntax is agnostic of the underlying async library, but Asyncio and Trio provide incompatible async "primitives". So yes, you need to write your code for one or the other, or use Anyio, which is a common layer over both. Many more libraries use Asyncio than Trio, so I have come to recommend Anyio (which has a Trio-like API) but with Asyncio as the backend. That gives you the extensive Asyncio ecosystem but with the structured concurrency design of Trio.
nerdponx 5y ago
As yet another option, I really like Anyio, which is a "frontend" to either Asyncio or Trio, which provides a consistent and tidy API for what is known as "structured concurrency" (I think the name was popularized by the C library Dill). https://anyio.readthedocs.io https://anyio.readthedocs.io