[Python-Dev] Thoughts fresh after EuroPython

[Gregory P. Smith]

On Sat, Jul 24, 2010 at 7:08 AM, Guido van Rossum <guido at 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.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100725/d89a2e12/attachment.html>