[Python-Dev] Thoughts fresh after EuroPython

[Peter Portante]

On 7/25/10 3:19 PM, "Gregory P. Smith" <greg at krypto.org> wrote:

> 
> 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.

+1

And there is so much legacy software out there that depends on single
coherency systems that it is unlikely such a memory architecture would
become pervasive, given the hurdle of rewriting those programs, python
programs included.

>> 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.

+1

> 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.

+1

FWIW: We use Python at Tabblo, straddled across Python 2.5.4 and 2.6.5. They
work. And they work well. But we make light use of threads (mostly
background I/O handling), and heavy use of multiple processes because we
can't take advantage of our multi-core systems otherwise.

-peter

> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/peter.a.portante%40gmail.com