Right, and single thread performance won’t matter as much if it becomes easier to implement multithreading. This hurts legacy code, but I imagine it would be worth it in the long run.
It would remain as hard as it has always been. Also threads are very heavy, locking kills performance, and if you don't have GIL, you'll need to manage explicit locks, that will be just as slow but also cause an incredible amount of subtle bugs.
> if you don't have GIL, you'll need to manage explicit locks
You need to do that with multithreaded Python code with the GIL. The GIL only guarantees that operations that take a single bytecode are thread-safe. But many common operations (including built-in operators, functions, and methods on built-in types) take more than one bytecode.
> locking kills performance, and if you don't have GIL, you'll need to manage explicit locks
I was under the impression that the Python thread scheduler is dependent on the host OS (rather than being intelligent enough to magically schedule away race conditions, deadlocks, etc.), so you still need to manage locks, semaphores, etc. if you write multi-threaded Python code. I don't see how removing the GIL would make this any worse. (Maybe make it slightly harder to debug, but at that point it would be in-line with debugging multi-threaded Java/C/etc. code.)
Or would this affect single-threaded code somehow?
In python you always have a lock, the GIL. If you take it away you end up actually having to do synchronization for real. Which is hard and error prone.
