3 ms·

Most code seems to take sides: it’s either synchronous or not (which I suppose in itself isn’t great). For many good standard libraries/packages, there is now a

Most code seems to take sides: it’s either synchronous or not (which I suppose in itself isn’t great). For many good standard libraries/packages, there is now an async variant. I used asyncio for the first time seriously recently and was pleasantly surprised. But, crucially, I didn’t want throughput, I wanted a low-cpu use app with easy-to-write concurrency. I really hope GIL goes away and we can just use threads.

nextaccountic 5y ago
I really hope GIL goes away so that async tasks can be dispatched in many threads, like done in Go or Rust. Something like one thread per core, plus work stealing to distribute tasks in threads. Dealing with threads directly is significantly worse. It's harder to do task cancellation, harder to do timeouts, you often need to reach for locks for the simplest things.
abrookins 5y ago
Async Python has proven faster in my uses for IO and non-CPU-related stuff. But I think Python, either as a community or within the language, needs to solve the anti-pattern of maintaining separate sync and async versions of a library. I'm thinking specifically of aioredis and redis-py, both of which I've worked on. Some people are looking at ways to solve this. I know urllib3, elasticsearch-py, and a few others use unasync (https://github.com/python-trio/unasync https://github.com/python-trio/unasync) to transform async code into sync code, leaving one codebase supporting both uses in different namespaces. This leaves you with some conditional logic (is_async_mode() -- https://github.com/python-trio/hip/blob/master/src/ahip/util/unasync.py#L8 https://github.com/python-trio/hip/blob/master/src/ahip/util...). I'm seriously considering this approach.
- VWWHFSfQ 5y ago
  > to transform async code into sync code oh my goodness.. So now we have sync code, that we've made into async code, that we now have to turn back into sync code! It's just workarounds upon workarounds upon workarounds. This is beyond the pale.

nextaccountic 5y ago

I really hope GIL goes away so that async tasks can be dispatched in many threads, like done in Go or Rust. Something like one thread per core, plus work stealing to distribute tasks in threads. Dealing with threads directly is significantly worse. It's harder to do task cancellation, harder to do timeouts, you often need to reach for locks for the simplest things.

abrookins 5y ago

Async Python has proven faster in my uses for IO and non-CPU-related stuff. But I think Python, either as a community or within the language, needs to solve the anti-pattern of maintaining separate sync and async versions of a library. I'm thinking specifically of aioredis and redis-py, both of which I've worked on. Some people are looking at ways to solve this. I know urllib3, elasticsearch-py, and a few others use unasync (https://github.com/python-trio/unasync https://github.com/python-trio/unasync) to transform async code into sync code, leaving one codebase supporting both uses in different namespaces. This leaves you with some conditional logic (is_async_mode() -- https://github.com/python-trio/hip/blob/master/src/ahip/util/unasync.py#L8 https://github.com/python-trio/hip/blob/master/src/ahip/util...). I'm seriously considering this approach.

VWWHFSfQ 5y ago
> to transform async code into sync code oh my goodness.. So now we have sync code, that we've made into async code, that we now have to turn back into sync code! It's just workarounds upon workarounds upon workarounds. This is beyond the pale.