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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4