<br><div class="gmail_quote">On Sat, Jul 24, 2010 at 7:08 AM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org">guido@python.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
- Commit privileges: Maybe we've been too careful with only giving<br>
commit privileges to to experienced and trusted new developers. I<br>
spoke to Ezio Melotti and from his experience with getting commit<br>
privileges, it seems to be a case of "the lion is much more afraid of<br>
you than you are afraid of the lion". I.e. having got privileges he<br>
was very concerned about doing something wrong, worried about the<br>
complexity of SVN, and so on. Since we've got lots of people watching<br>
the commit stream, I think that there really shouldn't need to be a<br>
worry at all about a new committer doing something malicious, and<br>
there shouldn't be much worry about honest beginners' mistakes either<br>
-- the main worry remains that new committers don't use their<br>
privileges enough. So, my recommendation (which surely is a<br>
turn-around of my *own* attitude in the past) is to give out more<br>
commit privileges sooner.<br></blockquote><div><br></div><div>+1 agreed!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
- Concurrency and parallelism: Russel Winder and Sarah Mount pushed<br>
the idea of CSP<br>
(<a href="http://en.wikipedia.org/wiki/Communicating_sequential_processes" target="_blank">http://en.wikipedia.org/wiki/Communicating_sequential_processes</a>) in<br>
several talks at the conference. They (at least Russell) emphasized<br>
the difference between concurrency (interleaved event streams) and<br>
parallelism (using many processors to speed things up). Their<br>
prediction is that as machines with many processing cores become more<br>
prevalent, the relevant architecture will change from cores sharing a<br>
single coherent memory (the model on which threads are based) to one<br>
where each core has a limited amount of private memory, and<br>
communication is done via message passing between the cores. This<br></blockquote><div> </div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
gives them (and me :-) hope that the GIL won't be a problem as long as<br>
we adopt a parallel processing model. Two competing models are the</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Actor model, which is based on asynchronous communication, and CSP,<br>
which is synchronous (when a writer writes to a channel, it blocks<br>
until a reader reads that value -- a rendezvous). At least Sarah<br>
suggested that both models are important. She also mentioned that a<br>
merger is under consideration between the two major CSP-for-Python<br>
packages, Py-CSP and Python-CSP. I also believe that the merger will<br>
be based on the stdlib multiprocessing package, but I'm not sure. I do<br>
expect that we may get some suggestions from that corner to make some<br>
minor changes to details of multiprocessing (and perhaps threading),<br>
and I think we should be open to those (I expect these will be good<br>
suggestions for small tweaks, not major overhauls).<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>-gps</div><div><br></div></div>