Because it's not a huge game changer.
What would you do differently if the GIL was gone?
when people need speed in Python they write C/C++ extensions or use multiple processes/computers
That is just not true.
1 - This helps parallelize regular python code too, like the kind that goes into writing web services.
2 - While you'd still write native extensions to get optimum performance for single threaded code, having the thread dispatch layer in python makes parallelizing execution convenient and robust. For example, see the comment from people who maintain scikit-learn below. I'd love to see python get composable task parallelism like Julia where you can freely spawn threads within threads without worrying about their lifetimes.
link: https://github.com/colesbury/nogil/issues/36#issuecomment-10...
> helps parallelize
> convenient and robust
So nice but not too noticeable?
What percentage of compute time is python?
What percent of Py compute time would be cut?
Who's using python?(banks, stem researchers, everyone else)
> ...bunch of questions...
Yeah, if you claim that something is a "game changer" you should provide some arguments, not questions/"help determine".
It might very well be a game changer but thud far you have only suggested there might be an argument for that, if ...
Edit: For backend services it would probably put Python around one order of magnitude away from Go in terms of memory usage to serve the same load, enough for teams not to consider switching.
Currently, that doesn't do much. Trying to do this with a processPool either works, or becomes a horrible exercise in fighting with pickle or whatever other serializer you pick.
What would I do differently? Actually make engineering choices based on the current project status and priorities without having those choices made for me.