At our Pythonlabs meeting today, we decided we needed a more formal
and organized way to track all the language and other changes being
discussed on python-dev. Someone else (I don't remember who)
suggested an IETF-like approach. I like that as a model, but am not
sure how much of that formalism we need to adopt (or is even
appropriate for us).
Since my finger was slowest reaching my nose, I got elected Editor.
On the positive side of that, I get to make the early decisions that
will be cursed for generations of Python hackers to come.
In any event, here's what I've just checked in.
These things are called PEPs or Python Enhancement Proposals. Each
has a number assigned to it by the Editor (me) which never changes
over the lifetime of the proposal. The format is very loosely defined
right now, but I'm sure will undergo formalization itself over time.
Essentially, each PEP starts with a bunch of RFC822 style headers.
Required headers are
PEP: the number assigned by the editor
Title: the title as given by the owner of the PEP
Version: usually $Revision$
Owner: the owner/champion/shepherd of the PEP
Status: the status as chosen from a currently very ill-defined set
Optional headers are
Python-Version: what version of Python this pertains to
PEP 0 (zero) is the index of PEPs. PEP 1 will be the PEP Guidelines
document (essentially this email message when it reflects back to my
mailbox). I'll continue to own both these for the time being.
PEP 200 is the Python 2.0 release schedule. Jeremy Hylton will own
this one.
PEP 201 discusses the parallel iteration feature. I currently own
this one, and have fleshed this out completely based on my
understanding of the issues as of 2:45am 13-Jul-2000. Use this as an
example of the PEP format until PEP 1 is completed.
PEP 202 will cover list comprehensions. I think Tim Peters
volunteered to own this one.
PEP 203 will cover augmented assignments. Thomas Wouters, we were
thinking about you owning this one.
My thoughts for these documents are that they will be almost
completely self-contained, so that someone freshly coming on the issue
can read the PEP, understand what the problem is, how the proposed
solution works, and where to go to find more information. Wading
through, or even following, the python-dev mailing list or archives
should not be necessary.
Another advantage is that these things will live in the Python CVS
tree, so they will be diff-able, modifiable by anybody with check-in
privileges, and will have the complete history in their CVS logs.
What I don't want to do: argue about meta issues, such as whether PEPs
are a good acronym, or whether we should use plain text or XML, or
whether I've had enough sleep lately. They probably aren't, but I
couldn't think of anything better; plain text is readable and writable
by everybody and I didn't want to waste time trying to write a DTD; I
haven't, so what's new?
You can find the current set of documents under nondist/peps in the
CVS tree. Please take a look, especially at pep-0201.txt which is
nearest to being complete.
Time for sleep.
-Barry
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