On Sat, Jul 24, 2010 at 7:08 AM, Guido van Rossum <guido@python.org> wrote:

- Commit privileges: Maybe we've been too careful with only giving
commit privileges to to experienced and trusted new developers. I
spoke to Ezio Melotti and from his experience with getting commit
privileges, it seems to be a case of "the lion is much more afraid of
you than you are afraid of the lion". I.e. having got privileges he
was very concerned about doing something wrong, worried about the
complexity of SVN, and so on. Since we've got lots of people watching
the commit stream, I think that there really shouldn't need to be a
worry at all about a new committer doing something malicious, and
there shouldn't be much worry about honest beginners' mistakes either
-- the main worry remains that new committers don't use their
privileges enough. So, my recommendation (which surely is a
turn-around of my *own* attitude in the past) is to give out more
commit privileges sooner.

+1 agreed!

- Concurrency and parallelism: Russel Winder and Sarah Mount pushed
the idea of CSP
(http://en.wikipedia.org/wiki/Communicating_sequential_processes) in
several talks at the conference. They (at least Russell) emphasized
the difference between concurrency (interleaved event streams) and
parallelism (using many processors to speed things up). Their
prediction is that as machines with many processing cores become more
prevalent, the relevant architecture will change from cores sharing a
single coherent memory (the model on which threads are based) to one
where each core has a limited amount of private memory, and
communication is done via message passing between the cores. This
I do not believe this prediction.  The dominant systems being deployed today have 4,6,8,12 cores on a single memory bus with coherent memory.  Sure, NUMA is clearly the dominant architecture but any subdivisions will still have multiple cores with access to the same coherent memory.  We'll just end up with multiples of that in one system.  The future architecture is _not_ the Cell processor.

gives them (and me :-) hope that the GIL won't be a problem as long as
we adopt a parallel processing model. Two competing models are the
Actor model, which is based on asynchronous communication, and CSP,
which is synchronous (when a writer writes to a channel, it blocks
until a reader reads that value -- a rendezvous). At least Sarah
suggested that both models are important. She also mentioned that a
merger is under consideration between the two major CSP-for-Python
packages, Py-CSP and Python-CSP. I also believe that the merger will
be based on the stdlib multiprocessing package, but I'm not sure. I do
expect that we may get some suggestions from that corner to make some
minor changes to details of multiprocessing (and perhaps threading),
and I think we should be open to those (I expect these will be good
suggestions for small tweaks, not major overhauls).

The async communication model is good regardless of individual architecture because it more readily grows out beyond a single computer to a network of computers when you want to scale an application up.  So yes, anything we can do to help that is good.

Hoping that the GIL won't be a problem has been a strategy for over a decade. It has failed. It is limiting what people can and will do with Python today.  It isn't going to magically un-become a problem.