The origin of the GIL is to keep the interpreter internals sane when running with multiple kernel threads. When it comes to problems involving parallelism, the easy solution is simple: serialize everything. So you get the GIL. Now, if that were the end of it, getting rid of the GIL would probably not that challenging. But, for better or for worse, the GIL also made a number of operations atomic that would not be in other languages. The Python FAQ has this example. Python programmers made use of these benefits in CPython, regardless of if the language designers actually guaranteed them. But at this point, it doesn't matter. The amount of code that depends on this behavior is large.
Greg Stein attempted to remove the GIL in Python 1.5, but programs ran about 2x slower than with the GIL. The reason being: in order to give people the guarantees they have grown accustom to in the previous paragraph, you need to do the locking on those operations for them. Where there was one a single lock, you now have a lock per object. And it is difficult to determine if an object will be accessed by multiple threads so the naive solution is to lock the object every time it's accessed in a way that needs to be atomic. This kind of fine-grained locking is expensive.
So this attempt didn't work. And it wasn't really a big deal. Multicore CPUs weren't that ubiquitous and people weren't doing things that would benefit that much from multiple cores. But now multicore is the rage and people believe that their Python programs will benefit from it. The common advice is simply to use
multiprocessing, but people tend to find this inadequate.
PyPy is trying to solve this using STM, and blog their progress. PyPy doesn't seem to be a solution for a lot of people yet and it's unclear how successful the STM approach will be.
If you really think multicore support is important to Python, then you don't want to pitch a fit about the GIL. What you want to do is convince the Python designers that you are OK with giving up those guarantees you have been taking advantage of over the years. You will rewrite your code to not make use of the guarantees. Then they can get rid of the fine-grained locking.
But... before you say "sure", make sure you know what you're getting into. If
L1.pop() is no longer thread-safe, then what does it mean if two threads access
L1 in parallel? I don't know much about threaded memory models but it could get pretty complicated. You might not be able to define all states of the program at that point.
In the future, before you pour too much hate on the GIL, remember: really just a symptom. The actual problem is, for simplicity, Python makes a number of guarantees that make executing performant code harder without the GIL than with it. And also, not everyone hates the GIL, some people are fond of the guarantees. Like this guy.