3 ms·
I don't see why you wouldn't have holdouts using GIL for valid single-threaded performance reasons for years/decades. And that's ignoring legacy code - even 2.
by Groxx 3y ago
I don't see why you wouldn't have holdouts using GIL for valid single-threaded performance reasons for years/decades. And that's ignoring legacy code - even 2.7 is still alive and kicking in some corners.
- jedberg 3y agoI'm sure you would, but anyone who cared about it would work around it, either by not using that library or finding a different one or even forking the one that isn't updated. Just like most people use Python 3.x now, but there are some 2.7 holdouts. But those holdouts aren't holding back the entire ecosystem at this point.
- Groxx 3y agoThey did for many, many years. And the result soured many devs and companies on Python. And many libraries have not been migrated. But yes, I'm very glad they've been cut off now. It does eventually shift to just the new stuff.
- zarzavat 3y agoThe difference is that no-GIL is a minority use case. Most people are using Python in single threaded workflows (numpy/scipy, machine learning, build scripts, etc etc) and who don’t care about the GIL. The GIL mostly affects webdevs. Probably the library support will be much worse than 2-3, but if only a minority of users are impacted by libraries that don’t support it then it’s not a big issue. GIL concerned users can either carefully select their dependencies to be no-GIL supporting, or they can decide to go with the GIL. 2-3 was bad because every single library, app, and tiny script had to be migrated, if it used a string or a print statement.