[Python-Dev] Python Enhancement Proposals (PEPs)
Thu, 13 Jul 2000 12:12:59 -0400 (EDT)
>>>>> "BAW" == Barry A Warsaw <firstname.lastname@example.org> writes:
>>>>> "PP" == Paul Prescod <email@example.com> 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> - we've reached consensus and now need just implement the
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> - 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." In the
Python community, we do believe in at least one benevolent dictator
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.