On 7/25/10 3:19 PM, "Gregory P. Smith" <greg@krypto.org> wrote:
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.
+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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/peter.a.portante%40gmail.c...