From reading the thread on HN the other day, it sounds like removing the GIL isn't really of much value. Maybe for somewhat obscure multithreading cases.
Is that right?
There are plenty of other Python VMs that don't have a GIL and can be used already today, out of the box (examples include Jython and IronPython). Despite that fact - CPython remains the most popular Python VM out there (it utilizes a GIL).
Instead of waiting for the GIL to be removed out of CPython - take your fancy Python code and just run it using a different VM. It's literally as simple as that.
If the GIL was such a bottleneck as people make it out to be - people would move off of CPython a long time ago. But they won't, despite having the options. This only serves to prove that 95%+ of the workflows people build with Python can be satisfied regardless of GIL, often using some of the other parallelism mechanisms available in Python today (multiprocessing, asyncio, etc).
Most of the stuff people build with Python are CRUD apps, Jupyter notebooks, automations, tinkering, small hacks, etc. If you're okay with not utilizing all of your 64k CPUs at home - Python's multiprocessing and asyncio libraries should serve you just fine.
The whole GIL/No-GIL conversation is a complete waste of time and a distraction. People have all the options they need already here and now - but slinging crap at eachother over an issue tracker is so much fun that people can't help it.
People stay on CPython due to the performance of C extensions and the vast ecosystem based on them. The fact that people have stuck with CPython isn't at all evidence that they like the GIL or that it doesn't lead to significant technical problems.
Besides the C extension issue, Jython is based on Python 2.7 and IronPython appears to be on 3.4. These aren't serious alternatives.