26 ms·
Asyncio is designed for things like webservers or UIs where some framework is probably already handling the main event loop. What are you doing where you just w
by hot_gril 2y ago
Asyncio is designed for things like webservers or UIs where some framework is probably already handling the main event loop. What are you doing where you just want to run something else in the background, and IPC isn't good enough?
- BugsJustFindMe 2y agoNon-blocking HTTP requests is an extremely common need, for instance. Why the hell did we need to reinvent special asyncio-aware request libraries for it? It's absolute madness. Thread pools are much easier to work with. > where some framework is probably already handling the main event loop This is both not really true and also irrelevant. When you need a flask (or whatever) request handler to do parallel work, asyncio is still pretty bullshit to use vs threads.
- hot_gril 2y agoNon-blocking HTTP request is the bread and butter use case for asyncio. Most JS projects are doing something like this, and they don't need to manage threads for it. You want to manage your own thread pool for this, or are you going to spawn and kill a thread every time you make a request?
- BugsJustFindMe 2y ago> Non-blocking HTTP request is the bread and butter use case for asyncio And the amount of contorting that has to be done for it in Python would be hilarious if it weren't so sad. > Most JS projects I don't know what JavaScript does, but I do know that Python is not JavaScript. > You want to manage your own thread pool for this... In Python, concurrent futures' ThreadPoolExecutor is actually nice to use and doesn't require rewriting existing worker code. It's already done, has a clean interface, and was part of the standard library before asyncio was.
- stavros 2y agoI feel you. I know asyncio is "the future", but I usually just want to write a background task, and really hate all the gymnastics I have to do with the color of my functions.
- BugsJustFindMe 2y agoI feel like "asyncio is the future" was invented by the same people who think it's totally normal to switch to a new javascript web framework every 6 months.
- hot_gril 2y agoJS had an event loop since the start. It's an old concept that Python seems to have lifted, as did Rust. I used Python for a decade and never really liked the way it did threads.
- zo1 2y agoPython's reactor pattern, or event loop as you call it, started with the "Twisted" framework or library. And that was first published in 2003. That's a full 6 years before Node.js was released which I assume was the first time anything event-loopy started happening in the JS world. I forgot to mention that it came into prominence in the Python world through the Tornado http server library that did the same thing. Slowly over time, more and more language features were added to give native or first-class-citizen support to what a lot of people were doing behind the scenes (in sometimes very contrived abuses of generator functions).
- hot_gril 2y agoYeah, this pattern is old. But JS is the only common language (at least today) that went so all-in with it.
- stavros 2y agoI agree, I find Go's way much easier to reason about. It's all just functions.
- kristjansson 2y agoYou don’t? concurrent.futures.ThreadPoolExecutor can get a lot done without touching async code.
- BugsJustFindMe 2y agoI am a big advocate for ThreadPoolExecutor. I'm saying it's superior to asyncio. The person I'm responding to was asking why use threads when you can use asyncio instead.
- kristjansson 2y agoAch, I posted before I saw the rest of your thread, apologies. Totally agree, concurrent.futures strikes a great balance. Enough to get work done, a bit more constrained than threads on their own. Asyncio is a lot of cud to chew if you just want a background task in an otherwise sync application
- d0mine 2y agoOrdinary CPython code releases GIL during blocking I/O. You can do http requests + thread pool in Python.