[Python-Dev] Thoughts fresh after EuroPython

[Jesse Noller]

On Sat, Jul 24, 2010 at 10:08 AM, Guido van Rossum <guido at 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.