[Python-Dev] Thoughts fresh after EuroPython

Sun Jul 25 02:04:57 CEST 2010

On 7/24/2010 3:08 PM, Guido van Rossum 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.
> 
+1. I think this would have a very positive effect on the way that the
Python development community id perceived from the outside. In reality
it's probably mostly an acceptance of the fact that new protocols are
appropriate with a rather larger development community.

> - 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.)
> 
I can understand the temptation, but hope you can manage to resist it.

The downside of allowing such exceptions is that people won't take these
pronouncements seriously if they see that a sufficiently desirable goal
is a reason for ignoring them. Everyone should be subject to the same rules.

> - 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.)
> 
I think the process where Jesse steered PEP 3148 worked well.

> - 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.
> 
There is indeed. PyPi has been troublesome in the past mostly because
while many people have strong opinions on how it should work, only
Martin has put in much time to try and improve it (and has had precious
little thanks for that). The site will definitely benefit from wider
community involvement, and I think that your suggestions about opening
up the developer community will also help relay the message that people
are welcome to help on other aspects of Python such as the cheese shop.

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

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/