curio

see also https://github.com/dabeaz/curio

I recently came across Curio (https://github.com/dabeaz/curio) & really appreciated their FAQ section on contributing. I plan to use it in any future open source projects: Q: Can I contribute? A: Curio is not a community-based project seeking developers or maintainers. However, having it work reliably is important. If you've found a bug or have an idea for making it better, please file an issue.

This is great recommendation, you can get very far by reading well written code. These have very well written Python, exposing much of the language expressiveness: - https://github.com/python-attrs/attrs - https://github.com/mahmoud/glom - https://github.com/pytoolz/toolz - https://github.com/Suor/funcy - https://github.com/dabeaz/curio ps: dabaez has great educational content on writing idiomatic python, definitely worth checking out An honorable mention of norvig's classic essays, which got me into python while I was in college, over 12y ago: https://norvig.com/spell-correct.html. Aside from reading code, _writing_ something that you know it exist (e.g glom) and then comparing it to how others have done it is also a great learning experience.

I did some work on html2text when I started off and while the little parts did make sense, the whole library was confusing for me. I couldn't change anything without breaking tests. On the other hand I've been tinkering with curio for a while now and it's a fresh breath compared to that. My trouble is that I still don't understand what makes the html2text thing "bad". What particular thing there caused me to not like working with it? I'm trying to understand that. I've been book hunting + figuring out if it's something that I did not know which would have made the code a lot easier to work with (stuff got a lot easier after I cleaned up my set theory understanding) - https://github.com/dabeaz/curio - https://github.com/Alir3z4/html2text

Slightly modified "benchmark" from above: asyncio: import time import asyncio REPS = 1_000_000 async def coro(): for i in range(REPS): await asyncio.sleep(0) t0 = time.perf_counter() asyncio.run(coro()) dt = time.perf_counter() - t0 print(REPS / dt, 'reps/s') ~180k asynker (https://github.com/enkore/asynker): import time import asynker REPS = 1_000_000 async def coro(): for i in range(REPS): await asynker.suspend() t0 = time.perf_counter() sched = asynker.Scheduler() sched.run_until_complete(coro()) dt = time.perf_counter() - t0 print(REPS / dt, 'reps/s') ~900k The excellent curio (https://github.com/dabeaz/curio): import time import curio REPS = 1_000_000 async def coro(): for i in range(REPS):

I'm curious of your take on Trio or Curio. Do either address the peeves you've outlined? https://github.com/python-trio/trio https://github.com/dabeaz/curio

What downsides of frameworks cause you to want a domain-specific language? Python is great at extending the language using frameworks, and I think the addition of async/await and event loop libraries makes it really fun to do agent-based programming using coroutines, especially with the Curio library[0]. Given async/await, coroutines, and a good library to drive the event loop, what else is missing that you would like language-level support for? 0: https://github.com/dabeaz/curio

"David Beazley's live demo hacked up asyncio replacement is twice as fast" Here it is if you are curious... :) https://github.com/dabeaz/curio

There are other implementations, such as Curio (https://github.com/dabeaz/curio) or Trio (https://github.com/python-trio/trio). Both are simpler and more hand-holdy (and less footgun) than asyncio. Disclaimer: I am a trio dev, though.

> Python's going to have a bit of an awkward time with two completely different sets of ecosystem for threaded vs. asyncio approaches, but it's necessary progress. It's threaded vs async/await (and even then projects like https://github.com/dabeaz/curio bridge that gap really well), rather than threaded vs asyncio. asyncio is just one (really really poor) implementation of async/await coroutines on Python. > One thing I'd be really keen to see is asyncio frameworks starting to consider adopting ASGI as a common interface. From what I've seen of the ASGI spec, it makes it incredibly easy (like most asyncio stuff) to DoS yourself with lack of backpressure. You get your callback called with data, and like all callback systems you can't exactly not get called.

The conclusion to stick to Python 2 just because the author does not like some optional features added in Python 3 seems far fetched. While the typing thing has been discussed here yesterday[0], I share his views about asyncio. I was a bit disappointed when asyncio lost its provisional status in Python 3.6. I was hopping that the community will wait a bit more and settle on something else. The work that David Beazley does on Curio[1] is amazing. This should be an inspiration for the standard library in my opinion. [0] https://news.ycombinator.com/item?id=13730494 [1] https://github.com/dabeaz/curio

Beazly is a genius and a huge boon to the community. Check out curio: his answer to relatively slow asyncio https://github.com/dabeaz/curio