And when did core developers downplay or dismiss the limitations of the GIL?

This very post presents when.

In my experience [and opinion] people who are serious about contributing to a project – and they are the ONLY PEOPLE WHO MATTER

I respect the fact that you have a different opinion and experience than I do. I value people’s time a lot more, and have great experience with receiving contributions from people that at first were unable to help. These facts are probably related.

And when did core developers downplay or dismiss the limitations of the GIL? This has been well documented and discussed endlessly.

Complaining is NOT contributing. Neither is trotting into the middle of something and just dropping off your ideas. That is not helpful. I’ve been involved in Open Source for over a decade and I’m solidly with the Brett regarding his points.

In my experience [and opinion] people who are serious about contributing to a project – and they are the ONLY PEOPLE WHO MATTER – will make an effort to discover the proper channels for contributing. Casual interlopers, big-thinkers, and visionaries are nothing more than distractions; they fatigue discussions and give the discussions an exaggerated sense of negativity, in addition to just soaking up time [replying to their messages].

I’m amazed how much people still think that shared mutable state is the way to go, although there are zillions of projects out there in hunderds of languages with the same problems.

The GIL is far from solving these problems, because it does not prevent shared mutable state between threads. What solves these problems is designing applications and frameworks which enable people to more easily reason about concurrency, and there are very good patterns evolving which enable people to reason more easily about concurrency in the same process space. When I see people claiming for concurrency, I don’t naïvely assume they’re designing something improperly.

There is a good chance that 20+cores don’t have one big shared memory and then the so called GIL problems vanish anyway.

This statement only makes any difference if you think that we’re going back to a model where each core works in isolation, but reality is that having several cores with access to shared memory isn’t going away.

I’m pretty sure that in the end PyPy will actually let me do this, in the meantime I’ll probably complain a little.

WRT fixing the GIL (not removing it):

I was a little disapointed that NIRs work to add a scheduler to python didn’t go through
http://bugs.python.org/issue7946

It looked very promising. From the outside it looked like the author of the other solution wasn’t happy to step aside when a better solution came along.

In it’s current form, it seems like the GIL doesn’t actually perform properly, sucking away cycles on multicore.

The whole thing is disappointing, I’m looking forward to a time when we can run fast python in Pypy and move on from saying that certain kinds of program are not suited to the language: the language should be fixed, not the programmes change.

I would just light to say again that you guys do a great job developing Python and it *is* appreciated. It isn’t normal to post praises, but I am sure you have a lot of silent admires of your work who agree with not bleating unless they think they are part of a solution.

(Look, no buts

At which point I bet we’ll also get rid of reference counting and go with strict garbage collection. And maybe by then PyPy will be the reference implementation. And we’ll all have flying cars.

(…) but when you have to scale across multiple machines (for any variety of reasons including load, cost, locale, etc.) the GIL doesn’t really matter. I would argue as well that the situation where the GIL matters (computing on a single machine) is not necessarily where the majority of users actually develop. (…)

This is certainly true, but please realize that it reflects a biased view. The existing practices around Python reflect the capacity of the interpreter. Just as a useful exercise, look at Erlang and try to understand the relationship that developers have to concurrency, and the designs that are used even in web servers.

But when you consider most servers end up needing a design that doesn’t depend on a single process and the mobile platforms will most likely be single processor for the foreseeable future (…)

I foresee something quite different: http://j.mp/cbMkEg