[Python-Dev] Python Enhancement Proposals (PEPs)

Jeremy Hylton jeremy@beopen.com
Thu, 13 Jul 2000 12:12:59 -0400 (EDT)

>>>>> "BAW" == Barry A Warsaw <bwarsaw@beopen.com> writes:

>>>>> "PP" == Paul Prescod <paul@prescod.net> writes:

  PP> I'm not clear on the role of opinions in this process. Do all of
  PP> the opinions about a proposal go in the PEP:

  PP> |  * "I hate this, here's why"
  PP> |  * "I have a minor enhancement proposal"
  PP> |  * "Here is my competing proposal"

  BAW> In some sense yes, but it's the job of the owner/shepherd to
  BAW> follow the various threads, and include debate about the
  BAW> proposal as open issues.  This would all lead to one of these
  BAW> conclusions:

  BAW> - we've reached consensus and now need just implement the
  BAW> proposal 
  BAW> - we've reached an impasse and the BDFL will rule by decree 
  BAW> - the proposal is hopeless flawed and the idea should be
  BAW> dropped 
  BAW> - we need more information or research 
  BAW> - we're defering the proposal to a future release

This is the reason I suggested maintaining a separate mail archive of
discussion.  The PEP ought to represent a coherent proposal.  It
should discuss alternatives, but it should not be a compendium of all
discussion and every possible idea.

I would like to see something like the IETF model -- "rough consensus
and running code" -- adopted.  Python will be differently clearly,
because the whole slogan is "We don't believe in kings, presidents, or
voting.  We believe in rough consensus and running code."[1]  In the
Python community, we do believe in at least one benevolent dictator
for life.

I propose the following guidlines:

The PEP author is responsible for developing what he or she believes
is a complete and coherent proposal.

To be adopted, the PEP must constitute either the consensus opinion of
the community (as determined by the PEP editor, Barry "Jon Postel"
Warsaw) *or* be endorsed by Guido.

It seems possible that we could have two different proposals for the
same feature, which suggests we might want to have some notation about
the final status of a PEP, e.g. accepted, rejected, etc., or that we
have something like Internet drafts that will become PEPs only if


Note 1: People have suggested that it's actually the opposite: running
consensus and rough code.