[Python-Dev] PEP Process Inefficient?

Jeremy Hylton jeremy@alum.mit.edu
Wed, 22 Nov 2000 09:50:22 -0500 (EST)


>>>>> "MZ" == Moshe Zadka <moshez@zadka.site.co.il> writes:

  MZ> The PEP process, while *miles* better then anything I've seen in
  MZ> any other development process I've ever seen, has some

(Not that we've used the PEP process for much of anything yet.
Except, I guess, extended print, which I've grown quite fond of.)

  MZ> deficiencies.  I'll try to point them out, and to suggest some
  MZ> partial solution:

I don't like your partial solution, so I'll try to pick about the
problems with the process <0.8 wink>.  Put another way: I can't
envision Slashdot as a useful design forum, but am interested in
improving the PEP process.  

  MZ> 1. Users are not sure who to post PEP questions/remarks to:
  MZ>    Python dev?  the original author? The Python devver they know
  MZ>    best?

In the absence of a reason to post elsewhere, the comments ought to be
sent to the PEP author.  If the message is intended to provoke wider
discussion, then the user can post it on any relevent forum (and cc
the PEP author).  A Unicode PEP might be discussed on the i18n-sig; a
Web PEP on the python-web-modules list; a change to core Python on
python-dev. 

I don't think there will ever be a rule that says: "Comments on PEP
1812 must be posted to the pep-1812 web forum."  Discussion should
occur in the forum in which it is most relevent.  Perhaps we could all
send our comments to Andrew, and he could write a bi-weekly
pep-comment summary <wink>.

Is the problem that you don't know where to post comments on someone
else's PEP, or that you are having trouble keeping track of
discussions in multiple places?

  MZ> 2. It is the responsiblity of the PEP author to add open
  MZ>    questions/pertinent remarks to the PEP.

What is the deficiency with this approach?  The PEP is supposed to
present a coherent proposal and design for a new language feature.
It is the designer's responsibility to write a good design document;
several people can share responsibility for the design.

Are you saying it's a problem that the PEPs aren't open to
modification by anyone?  (The last thing we need is someone who
doesn't understand what a first-class function is messing with the
scoping PEP <0.2 wink>.)

The designer is responsible for discussing trade-offs and alternatives
to justify her design.  This is where the responsibility to address
questions and comments comes from.

  MZ> 3. Mail about the PEP which contains important discussion is
  MZ>    lost.

How?  I've got all the mail on the nested static scopes PEP.  Is the
problem just the personal burden of keeping track of lots of mail
messages discussing a PEP?

Any discussion that occurs on a mailing list will be preserved in the
mailing list archive.  That's not lost.  So the only problem would be
with discussion that occurs in private email, where everyone deletes
copies of the mail.

I wonder if the key problem is not having an authoritative mail
archive for the PEP.  One part of the Scheme RFI process that we did
not copy was having a mail archive for each document.  Perhaps this
would be sufficient to address your concerns.  If you, the PEP author,
receive a comment by private email, you could bounce it to the
archive.

the-biggest-problem-with-the-PEP-process-is-no-one-writing-PEPs-ly y'rs,
Jeremy