Earlier quoted context omitted.
The GIL is optional in new Python versions. Downsides are legacy library compatibility and degraded single thread performance.
I mentioned subinterpreters. That’s the thing that “makes the GIL optional,” you still have to use subinterpreters. Is this no longer true?
Python has had async for 10 years – why isn't it more popular?
301–305 of 305 posts
Re: Python has had async for 10 years – why isn't it more popular?
#302Re: Python has had async for 10 years – why isn't it more popular?
#303Earlier quoted context omitted.
We used callbacks and generators. It was a bit messy at times, but really, it wasn't all that different. I still use generators quite often.
Oh... only a "bit" messy, you say? ;)
I think there's a good reason as well that async generators are at the core of async/await, but people rarely use them outside of abstractions. I like them, but they are a lower level tool for sure. Once they 'click' and you feel good with them, great, but chances aren't very good that everyone you work with will feel the same.
Generators add on a sort of cognitive overhead more than mess, I guess. Sometimes it makes sense to pull them out, but often it doesn't. Promises probably encapsulate 95% of common use cases. Promises just do one thing, whereas everywhere you use generators, you've got all the power and potential of generators. Kind of a 'great power, great responsibility' problem
Re: Python has had async for 10 years – why isn't it more popular?
#304With POSIX, you can only really do blocking filesystem I/O. There's an API for async I/O, where readiness of any read/write operation can either deliver a signal, or start a new thread. Neither of these scale at all. Things like select, poll, epoll all block, even with O_NONBLOCK.
So if your application needs to read files which may be large, or on a slow filesystem (or even networked filesystems!), you're now working with blocking I/O, at which point async can't help you.
---
Obviously this isn't the root cause of "why hasn't async taken over". It's just one of the many reasons which all pile up.
Re: Python has had async for 10 years – why isn't it more popular?
#305Not too long ago, I read a comment on HN that suggested, due to Python's support for free-threading, async in Python will no longer be needed and will lose out to free-threading due to it's use of "colored" functions. Which seems to align with where this author ends up: > Because parallelism in Python using threads has always been so limited, the APIs in the standard library are quite rudimentary. I think there is an…
If you have 1 async thread, 4 very slow clients don't impact your server in the slightest.