4 ms·

I love python but I think the language will slowly die if they don't do something about the GIL. So these syntax improvements are nice but not exciting.

d0mine 5y ago
There were GILless Python implementations before, they didn't replace implementations that use GIL (CPython, Pypy).
- fabioz 5y ago
  Yes, but Jython and IronPython (which were the only implementations that I know of that effectively didn't have a GIL) were much slower in general, didn't work with native extensions and were always lagging a lot on the supported version (so, yes, there's not much interest in having a GILless version with these shortcomings -- so, IMHO, CPython is right in only accepting a GIL removal if the performance in general doesn't suffer and which has a good path forward for compatibility of the existing native extensions ecosystem).
Zababa 5y ago
Why do you think that? I personally think that the main "blocker" for Python is package management and installation, but that doesn't stop it from being popular.
PeterisP 5y ago
See the recent discussion at https://news.ycombinator.com/item?id=29005573 https://news.ycombinator.com/item?id=29005573 - it seems to be coming and there's ongoing work to start merging a solution to GIL in the work-for-3.11 branch. They do say "Don’t expect Python 3.11 to drop the GIL just yet", but it seems likely that either 3.11 or 3.12 will have a GIL-less option that you can enable if you don't rely on any C extensions that need extra work to become concurrency-safe.
fabioz 5y ago
Well, I wouldn't say that it'll slowly die given that there are many workarounds one can use to use multiple processors for CPU-heavy workloads even when the GIL is present (such as releasing it in native extensions or using multiprocessing). So, while it's discussed a lot, it seems like it did become one of the most popular languages even having a GIL -- but I guess we'll never know for sure as there are real plans to make a GILless CPython now...

d0mine 5y ago

There were GILless Python implementations before, they didn't replace implementations that use GIL (CPython, Pypy).

fabioz 5y ago
Yes, but Jython and IronPython (which were the only implementations that I know of that effectively didn't have a GIL) were much slower in general, didn't work with native extensions and were always lagging a lot on the supported version (so, yes, there's not much interest in having a GILless version with these shortcomings -- so, IMHO, CPython is right in only accepting a GIL removal if the performance in general doesn't suffer and which has a good path forward for compatibility of the existing native extensions ecosystem).

Zababa 5y ago

Why do you think that? I personally think that the main "blocker" for Python is package management and installation, but that doesn't stop it from being popular.

PeterisP 5y ago

See the recent discussion at https://news.ycombinator.com/item?id=29005573 https://news.ycombinator.com/item?id=29005573 - it seems to be coming and there's ongoing work to start merging a solution to GIL in the work-for-3.11 branch. They do say "Don’t expect Python 3.11 to drop the GIL just yet", but it seems likely that either 3.11 or 3.12 will have a GIL-less option that you can enable if you don't rely on any C extensions that need extra work to become concurrency-safe.

fabioz 5y ago

Well, I wouldn't say that it'll slowly die given that there are many workarounds one can use to use multiple processors for CPU-heavy workloads even when the GIL is present (such as releasing it in native extensions or using multiprocessing). So, while it's discussed a lot, it seems like it did become one of the most popular languages even having a GIL -- but I guess we'll never know for sure as there are real plans to make a GILless CPython now...