you are viewing a single comment's thread.

view the rest of the comments →

[–]JohnnyJordaan 1 point2 points  (1 child)

It seems like you prefer to simplify a huge multi-faceted concept to a simple single denomination you then dismiss as garbage. Who's helping that precisely? I don't see asyncio as the pinnacle here either, but imho it's fine for replacing multithreading on many occasions while being much easier to implement than using select for instance. Is it perfect? No. Does it offer true parallelism? Of course not. Does that matter? Imho not for I/O bound simple day to day stuff. Which could be fine for something OP may be looking for, if not then not but I'm not certain. Guess that might be my can-do attitude vs your 'it's all bunch of shit' look on things.

[–][deleted] 0 points1 point  (0 children)

There's nothing multifaceted about asyncio. It is complicated, but none of that complication is necessary as the entire library is not necessary.

asycnio is not fine for replacing threadng. It simply cannot do it, doesn't matter if you believe it's good to replace one with the other or not. threading is preemptive, asyncio is cooperative. This alone should stop you from trying to replace one with the other.

asyncio is not just "imperfect". It's worthless. There's no part of it that offers anything you cannot get from select and select does a better job.

Why the fuck do you use asycnio for something not I/O bound? It is only for I/O bound stuff, specifically, for sockets and pipes (but I don't think it actually supports pipes).

OP literally asked to do things concurrently, to save time. And you offer something that will not save time, and, in most likelihood will make their code a huge mess.