[Python-Dev] Python Enhancement Proposals (PEPs)

[Jeremy Hylton]

At our meeting yesterday Tim suggested that each enhancement or
language feature have two documents -- a specification and a
rationale.  It looks like Barry did not adopt that suggestion
explicitly, but I think it's still a good approach for writing a
single PEP.

Each PEP should have a brief technical specification of the new
feature.  For a feature like augmented assignment, it would need to
specify the syntax and semantics of each operation on each type and on
the overloading mechanism for classes, e.g. is "a += b += c" valid
syntactically and what does it mean.

The PEP should also have a rationale that describes why the
specification is the way it is.  It should discuss alternatives that
were considered and why there were not adopted.  Other topics
appropriate for the rationale might be motivation (why do we want this
feature at all?) and comparison (what do other languages do?).

The Scheme language has a similar mechanism called Scheme Requests for
Implementation (SRFI), <http://srfi.schemers.org/>. It is not exactly
the same, because Scheme seems to have no end of proposals that
include specification and rationale; they just can't agree on a
standard set <0.2 wink>.  We might adopt some of their processes for
the PEPs.

Two things that each SRFI that PEPs don't yet have are:

- a mail archive attached to the PEP that contains relevant
  discussion.  A mail archive seems valuable for people interested in
  the next level of detail, but I'm not sure what mechanism to use to
  create one.  (It also seems valuable because the old "search
  dejanews" certainly isn't stable in the long-term.)  Maybe PEP
  authors could maintain their own archives.

- a copyright notice.  As a strawman, I propose that the owner/author
  of each PEP retains copyright, but must publish it under the
  OpenContent license, <http://opencontent.org/opl.shtml>.

Jeremy