WingNews logo WingNews
top | item 32002346

(no title)

siekmanj | 3 years ago

Python has actually had concurrency since about 2019: https://docs.python.org/3/library/asyncio.html. Having used it a few times, it seems fairly sane, but tbf my experience with concurrency in other languages is fairly limited.

edit: ray https://github.com/ray-project/ray is also pretty easy to use and powerful for actual parallelism

discuss

order

BugsJustFindMe|3 years ago

I find asyncio to be horrendous, both because of the silliness of its demands on how you build your code and also because of its arbitrarily limited scope. Thread/ProcessPoolExecutor is personally much nicer to use and universally applicable...unless you need to accommodate Ctrl-C and then it's ugly again. But fixing _that_ stupid problem would have been a better expenditure of effort than asyncio.

coldtea|3 years ago

>I find asyncio to be horrendous, both because of the silliness of its demands on how you build your code and also because of its arbitrarily limited scope.

Do you compare it to threads and pools, or judge it on its merits as an async framework (with you having experience of those that you think are done better elsewhere, e.g. in Javascript, C#, etc)?

Because both things you mention "demands on how you build your code" and "limited scope" are part of the course with async in most languages that aren't async-first.

dekhn|3 years ago

Asyncio violates every aspect of compositional orthogonality just like decorators you can't combine it with anything else without completely rewriting your code around its constrictions. It's also caused a huge amount of pip installation problems around the AWS CLI and boto

Joker_vD|3 years ago

Having both Task and Future was a pretty strange move; and the lack of static typing certainly doesn't help: the moment you get a Task wrapping another Task wrapping the actual result, you really want some static analysis tool to tell you that you forgot one "await".

sgtlaggy|3 years ago

Concurrency in Python is a weird topic, since multiprocessing is the only "real" concurrency. Threading is "implicit" context switching all in the same process/thread, asyncio is "explicit" context switching. On top of that, you also have the complication of the GIL. If threads don't release the GIL, then you can't effectively switch contexts.

dragonwriter|3 years ago

> Concurrency in Python is a weird topic, since multiprocessing is the only "real" concurrency.

You are confusing concurrency and parallelism.

> Threading is "implicit" context switching all in the same process/thread

No, threading is separate native threads but with a lock that prevents execution of Python code in separate threads simultaneously (native code in separate threads, with at most on running Python, can still work.)

hn_saver|3 years ago

Threading IS concurrency. When you say "real" concurrency, you actually mean parallelism.

uniqueuid|3 years ago

I have used asyncio in anger quite a bit, and have to say that it seems elegant at first and works very well for some use cases.

But when you try to do things that aren't a map-reduce or Pool.map() pattern, it suddenly becomes pretty warty. E.g. scheduling work out to a processpool executor is ugly under the hood and IMO ugly syntactically as well.

ikinsey|3 years ago

I love asyncio! It's a very well put together library. It provides great interfaces to manage event loops, io, and some basic networking. It gives you a lot of freedom to design asynchronous systems as you see fit.

However, batteries are not included. For example, it provides no HTTP client/server. It doesn't interop with any synchronous IO tools in the standard library either, making asyncio a very insular environment.

For the majority of problems, Go or Node.js may be better options. They have much more mature environments for managing asynchrony.

stepanhruda|3 years ago

I’m a fan of asyncio, the parent probably meant to say parallelism though, since that’s what getting rid of GIL unlocks.