Then you're not paying attention. No one (except a broken minority) said that they would not want to get rid of the GIL so long as single threaded performance was note degraded. Guido himself has stated this time and time again. The one thing missing to all the bright ideas and suggested ways of doing it?
Calling the GIL an implementation detail is like calling tail call elimination an implementation detail: for most software, it may be so, but there are idioms one may or may not be able to use depending on that detail. It's a visible implementation detail.
tail call elimination is a language feature. The GIL is an implementation detail of the Cpython interpreter. Jython, IronPython, and one day PyPy and Unladen-Swallow will not have a GIL.
Well, in other implementations like jython and iron python, the GIL doesn't exist, so I think most people would consider it just an implementation detail
Tail-call is an implementation detail. The fact that some people think it's as fundamental to programming as the Ten Commandments is to the Judeo-Christian tradition is... well, perhaps more a problem with programmers than with language implementations.
(and yes, it's visible, and that's one reason why I have issues with it -- it's a classic leaky abstraction, except in this case the "leak" is more like a torrential flood)
If your `while'-loops would crash after a certain number of iterations (and use linear memory before that), would you call that an implementation detail or a leaky abstraction? I'd call it a bug.
And special case constructs for linear recursion like `for' and `while' are only a necessary band-aid in languages that do not treat functions properly.
From what I have read, GvR and other core Python people are in favor of removing the GIL, but the solution to removing the GIL has to not hurt performance CPython and must not cause any regressions. Some have worked on replacing GIL, but have not finished the work.
