[Python-Dev] Thoughts fresh after EuroPython (original) (raw)
Guido van Rossum guido at python.org
Sat Jul 24 16:08:31 CEST 2010
- Previous message: [Python-Dev] http://bugs.python.org/issue231540
- Next message: [Python-Dev] Thoughts fresh after EuroPython
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
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).
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.)
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.)
Specifically, if Raymond is interested, I wouldn't mind seeing him as the PEP handler for PEP 380. For some of Martin von Löwis's PEPs (382, 384) I think a PEP handler is sorely lacking -- from the language summit it appeared as if nobody besides Martin understands these PEPs.
A lot of things seem to be happening to make PyPI better. Is this being summarized somewhere? Based on some questions I received during my keynote Q&A (http://bit.ly/bdflqa) I think not enough people are aware of what we are already doing in this area. Frankly, I'm not sure I do, either: I think I've heard of a GSOC student and of plans to take over pypi.appspot.com (with the original developer's permission) to become a full and up-to-date mirror. Mirroring apparently also requires some client changes. Oh, and there's a proposed solution for the "register user" problem where apparently the clients had been broken by a unilateral change to the server to require a certain "yes I agree" checkbox.
For a hopefully eventually exhaustive overview of what was accomplished at EuroPython, go to http://wiki.europython.eu/After -- and if you know some blog about EuroPython not yet listed, please add it there.
-- --Guido van Rossum (python.org/~guido)
- Previous message: [Python-Dev] http://bugs.python.org/issue231540
- Next message: [Python-Dev] Thoughts fresh after EuroPython
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]