ehiggs
commented
4 years ago I think "free threading" is a not-good name. Consider the following.
-
If the GIL is removed then all code using the threading module has the potential to break since people almost certainly haven't locked their code correctly.
-
To fix 1, landing gilectomy should require deprecation of the threading module so prevent destroying peoples' code. This means "free-threading" would be very deceptive since people shouldn't be using the 'threading' module.
Maybe people are happy with all threaded code being broken. So nothing needs to happen. But maybe we want to make sure people's code isn't broken when they upgrade to Python3.${something_with_gilectomy_landed}
-
Maybe people want guarantees that existing code still works. So initially Python with landed gilectomy should still run with GIL until code is run in a special environment (think: async being run on an async event loop, non-GIL code being run in a non GIL threadpool).
-
Something more ambitious and exotic: an actor model sitting on an async event loop that only allows messages to be passed between the actors. But it's a huge discussion.
I'd posit that Python has only 1 competitor in dynamic language world. That's modern JS (i.e. ES6/ES2016 with its implementation of async/await, etc.)
FWIW, that's not even remotely true. But we shouldn't worry about what other communities are doing and how to 'win' over them. Afterall, many of us are part of many communities. :)
TL;DR let's not make it about GIL.
Let's call it free-threading or multicore enhancements.
I'm for one tired of GIL-flame.
(Assume devil's advocate mode)
I'd posit that Python has only 1 competitor in dynamic language world. That's modern JS (i.e. ES6/ES2016 with its implementation of async/await, etc.)
That's a language and runtime that doesn't support threads at all, forget about free-threading.
It's a language with more human users, more runtimes active, and most importantly, a language where it's much easier to see the source code and therefore learn and improve (compare Python back-end against JS front-end, where source code, breakpoints, etc is just developer tools away).
Ultimately number of cores is still way smaller than number of open tabs or number of vms or containers someone provisions in the cloud.
Perhaps cores/native threads are the wrong focus?
Perhaps effort is better spent teaching existing Python developers new functionality? Or some form of run-from-github (e.g. pythonanywhere) whereas a regular end user can take a peek at the source code, learn from it, fork it and make their enhancements? Or getting Python to run nicely on mobile platforms?