On Sat, Jul 24, 2010 at 10:08 AM, Guido van Rossum <gu...@python.org> wrote: > While the EuroPython sprints are still going on, I am back home, and > after a somewhat restful night of sleep, I have some thoughts I'd like > to share before I get distracted. Note, I am jumping wildly between > topics. > > - 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.
I'd agree with this as well; speaking as someone who was terrified when I first got privileges, I can really back this up. However, I wonder if voluntary code reviews for bigger ticket items would be a good thing to encourage more. I know some people use rietveld - but maybe we should be using it more, plus emails to python-committers asking for reviews. As time has gone on, I've become more and more a firm believer in doing peer reviews. > - 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 > 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). I'm open to changes; but remain skeptical the CSP will suddenly take over the world :) There's other, competing philosophies and toolkits out there as well. Additionally; the patches would have to be relicensed - python-csp is under GPLv2 AFAICT. > - After seeing Raymond's talk about monocle (search for it on PyPI) I > am getting excited again about PEP 380 (yield from, return values from > generators). Having read the PEP on the plane back home I didn't see > anything wrong with it, so it could just be accepted in its current > form. Implementation will still have to wait for Python 3.3 because of > the moratorium. (Although I wouldn't mind making an exception to get > it into 3.2.) I, like others, want PEP 380 to be in and done (it's exciting!). However, we knew going into the moratorium that it would negatively affect PEP 380 - as a co-author, it was one of the few things which made me second-guess the implementation of the moratorium. So; in this case I'd have to vote no, we knew going in it would do this. > - This made me think of how the PEP process should evolve so as to not > require my personal approval for every PEP. I think the model for > future PEPs should be the one we used for PEP 3148 (futures, which was > just approved by Jesse): the discussion is led and moderated by one > designated "PEP handler" (a different one for each PEP) and the PEP > handler, after reviewing the discussion, decides when the PEP is > approved. A PEP handler should be selected for each PEP as soon as > possible; without a PEP handler, discussing a PEP is not all that > useful. The PEP handler should be someone respected by the community > with an interest in the subject of the PEP but at an arms' length (at > least) from the PEP author. The PEP handler will have to moderate > feedback, separating useful comments from (too much) bikeshedding, > repetitious lines of questioning, and other forms of obstruction. The > PEP handler should also set and try to maintain a schedule for the > discussion. Note that a schedule should not be used to break a tie -- > it should be used to stop bikeshedding and repeat discussions, while > giving all interested parties a chance to comment. (I should say that > this is probably similar to the role of an IETF working group director > with respect to RFCs.) > This reminds me of discussions I've had in some venues about Python adopting a lieutenant-based system ala the linux kernel. I'm a fan of what you're suggesting, but would take it one step further - the PEP handler should also be a committer, someone with experience working with the current core group so that the PEP handler can eventually help mentor (if needed) the new code (and possibly committer) through the integration process. _______________________________________________ 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/archive%40mail-archive.com
