Hacker News Reader

Comment by monos | Hacker News Reader

  > if someone came up with (otherwise acceptable)
  > changes to get rid of the GIL I wouldn't object.

that was the big news for me.

View on HN

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?

A patch.

thx for clarifying this. still a strange example since the GIL is not thought to be a problem, from what i read on pydev.

The GIL is an implementation detail; not a bug.

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.

Ergo, it is an implementation detail.

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.

Thank you for making my point eloquently.

The assumption that the way you prefer to write code should be the only way to write code is, well, exactly what I was talking about.

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.

Reply on news.ycombinator.com