3 ms·
They 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'
by Groxx 3y ago
They 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.