[derengel]

I don't know or use Python but why an implementation that is trying to be "superior" still has the GIL?

[huxley]

This donation page has some background on how PyPy is proposing to replace the GIL with software transactional memory:

http://pypy.org/tmdonate2.html#introduction

[pekk]

What DO you know or use? Did you think that the GIL was an obvious and stupid oversight made by stupid people for no good reason?

[glibgil]

Obviously the GIL was shortsighted, yes. Leave the people out of it. The idea was stupid. There was a reason, but it wasn't a good reason.

[rguillebert]

What would you replace it with ?

[glibgil]

No GIL.

[rspeer]

Your username is apt, but novelty accounts aren't a thing here. What exactly are you hoping to communicate?

[glibgil]

My name is Gil. Look at my comment history and apologize.

[rguillebert]

you need something to allow concurrent access to internal interpreter data structures...

[glibgil]

STM or MVar

[meowface]

Because it's very tricky to remove.

Ruby also has a GIL.

[dragonwriter]

> Ruby also has a GIL.

MRI has a GIL; major alternative implementations (JRuby, Rubinius) do not.

OTOH, addressing the downsides of a GIL are not the only reasonable motivations for an alternative implementation, so there's no reason that a better-than-stock Python (or Ruby) fundamentally must remove the GIL (the current "MRI" used to be an alternative, YARV, to the old MRI, and both had GILs.)

[meowface]

True. Jython and IronPython also do not have a GIL.