As far as I am aware, the big issue with removing the GIL is the vast amount of C based packages that depend on the GIL.
Not just internal packages, but a lot of third party ones.
That means removing the GIL would all of a sudden break a lot of code, and require a lot of packages to be rewritten. Inevitably, some will not be rewritten, remain broken, and a schism in Python might form again.
Perhaps Python should try making message passing based concurrency better. It tends to lead to more robust code than shared memory concurrency. I could see how that might be too far a departure from what people expect though.
Comments
As far as I am aware, the big issue with removing the GIL is the vast amount of C based packages that depend on the GIL. Not just internal packages, but a lot of third party ones.
That means removing the GIL would all of a sudden break a lot of code, and require a lot of packages to be rewritten. Inevitably, some will not be rewritten, remain broken, and a schism in Python might form again.
Perhaps Python should try making message passing based concurrency better. It tends to lead to more robust code than shared memory concurrency. I could see how that might be too far a departure from what people expect though.
So par for the course for the PSF?
Big discussion of this yesterday: https://news.ycombinator.com/item?id=28880782