[pypy-svn] rev 1929 - in pypy/trunk/doc/funding/pep-0001: . pep-0001_files

tismer at codespeak.net tismer at codespeak.net
Tue Oct 14 20:56:31 CEST 2003


Author: tismer
Date: Tue Oct 14 20:56:30 2003
New Revision: 1929

Added:
   pypy/trunk/doc/funding/pep-0001/
   pypy/trunk/doc/funding/pep-0001/pep-0001.html
   pypy/trunk/doc/funding/pep-0001/pep-0001.sxw   (contents, props changed)
   pypy/trunk/doc/funding/pep-0001/pep-0001_files/
   pypy/trunk/doc/funding/pep-0001/pep-0001_files/PyBanner046.gif   (contents, props changed)
   pypy/trunk/doc/funding/pep-0001/pep-0001_files/pep.css
Log:
added pep-001 source

Added: pypy/trunk/doc/funding/pep-0001/pep-0001.html
==============================================================================
--- (empty file)
+++ pypy/trunk/doc/funding/pep-0001/pep-0001.html	Tue Oct 14 20:56:30 2003
@@ -0,0 +1,462 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head><!--
+This HTML is auto-generated.  DO NOT EDIT THIS FILE!  If you are writing a new
+PEP, see http://www.python.org/peps/pep-0001.html for instructions and links
+to templates.  DO NOT USE THIS HTML FILE AS YOUR TEMPLATE!
+-->
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+  <meta name="generator" content="Docutils 0.2.8: http://docutils.sourceforge.net/"><title>PEP 1 -- PEP Purpose and Guidelines</title>
+  
+  <link rel="stylesheet" href="pep-0001_files/pep.css" type="text/css"></head>
+
+
+
+<body bgcolor="white">
+<table class="navigation" cellpadding="0" cellspacing="0" width="100%" border="0">
+<tbody><tr><td class="navicon" width="150" height="35">
+<a href="http://www.python.org/" title="Python Home Page">
+<img src="pep-0001_files/PyBanner046.gif" alt="[Python]" border="0" width="150" height="35"></a></td>
+<td class="textlinks" align="left">
+[<b><a href="http://www.python.org/">Python Home</a></b>]
+[<b><a href="http://www.python.org/peps/">PEP Index</a></b>]
+[<b><a href="http://www.python.org/peps/pep-0001.txt">PEP Source</a></b>]
+</td></tr></tbody></table>
+<div class="document">
+<table class="rfc2822 field-list" frame="void" rules="none">
+<col class="field-name">
+<col class="field-body">
+<tbody valign="top">
+<tr class="field"><th class="field-name">PEP:</th><td class="field-body">1</td>
+</tr>
+<tr class="field"><th class="field-name">Title:</th><td class="field-body">PEP Purpose and Guidelines</td>
+</tr>
+<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.43</td>
+</tr>
+<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/peps/pep-0001.txt">2003/05/07 00:03:13</a></td>
+</tr>
+<tr class="field"><th class="field-name">Author:</th><td class="field-body">Barry A. Warsaw, Jeremy Hylton, David Goodger</td>
+</tr>
+<tr class="field"><th class="field-name">Status:</th><td class="field-body">Active</td>
+</tr>
+<tr class="field"><th class="field-name">Type:</th><td class="field-body">Informational</td>
+</tr>
+<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="http://www.python.org/peps/pep-0012.html">text/x-rst</a></td>
+</tr>
+<tr class="field"><th class="field-name">Created:</th><td class="field-body">13-Jun-2000</td>
+</tr>
+<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">21-Mar-2001, 29-Jul-2002, 03-May-2003</td>
+</tr>
+</tbody>
+</table>
+<hr>
+<div class="contents topic" id="contents">
+<p class="topic-title"><a name="contents">Contents</a></p>
+<ul class="simple">
+<li><a class="reference" href="#what-is-a-pep" id="id27" name="id27">What is a PEP?</a></li>
+<li><a class="reference" href="#kinds-of-peps" id="id28" name="id28">Kinds of PEPs</a></li>
+<li><a class="reference" href="#pep-work-flow" id="id29" name="id29">PEP Work Flow</a></li>
+<li><a class="reference" href="#what-belongs-in-a-successful-pep" id="id30" name="id30">What belongs in a successful PEP?</a></li>
+<li><a class="reference" href="#pep-formats-and-templates" id="id31" name="id31">PEP Formats and Templates</a></li>
+<li><a class="reference" href="#pep-header-preamble" id="id32" name="id32">PEP Header Preamble</a></li>
+<li><a class="reference" href="#reporting-pep-bugs-or-submitting-pep-updates" id="id33" name="id33">Reporting PEP Bugs, or Submitting PEP Updates</a></li>
+<li><a class="reference" href="#transferring-pep-ownership" id="id34" name="id34">Transferring PEP Ownership</a></li>
+<li><a class="reference" href="#references-and-footnotes" id="id35" name="id35">References and Footnotes</a></li>
+<li><a class="reference" href="#copyright" id="id36" name="id36">Copyright</a></li>
+</ul>
+</div>
+<div class="section" id="what-is-a-pep">
+<h1><a class="toc-backref" href="#id27" name="what-is-a-pep">What is a PEP?</a></h1>
+<p>PEP stands for Python Enhancement Proposal.  A PEP is a design
+document providing information to the Python community, or describing
+a new feature for Python.  The PEP should provide a concise technical
+specification of the feature and a rationale for the feature.</p>
+<p>We intend PEPs to be the primary mechanisms for proposing new
+features, for collecting community input on an issue, and for
+documenting the design decisions that have gone into Python.  The PEP
+author is responsible for building consensus within the community and
+documenting dissenting opinions.</p>
+<p>Because the PEPs are maintained as text files under CVS control, their
+revision history is the historical record of the feature proposal
+<a class="footnote-reference" href="#id8" id="id1" name="id1">[1]</a>.</p>
+</div>
+<div class="section" id="kinds-of-peps">
+<h1><a class="toc-backref" href="#id28" name="kinds-of-peps">Kinds of PEPs</a></h1>
+<p>There are two kinds of PEPs.  A Standards Track PEP describes a new
+feature or implementation for Python.  An Informational PEP describes
+a Python design issue, or provides general guidelines or information
+to the Python community, but does not propose a new feature.
+Informational PEPs do not necessarily represent a Python community
+consensus or recommendation, so users and implementors are free to
+ignore Informational PEPs or follow their advice.</p>
+</div>
+<div class="section" id="pep-work-flow">
+<h1><a class="toc-backref" href="#id29" name="pep-work-flow">PEP Work Flow</a></h1>
+<p>The PEP editors assign PEP numbers and change their status.  The
+current PEP editors are David Goodger and Barry Warsaw.  Please send
+all PEP-related email to &lt;<a class="reference" href="mailto:peps at python.org">peps at python.org</a>&gt;.</p>
+<p>The PEP process begins with a new idea for Python.  It is highly
+recommended that a single PEP contain a single key proposal or new
+idea.  The more focussed the PEP, the more successful it tends to
+be.  The PEP editor reserves the right to reject PEP proposals if they
+appear too unfocussed or too broad.  If in doubt, split your PEP into
+several well-focussed ones.</p>
+<p>Each PEP must have a champion -- someone who writes the PEP using the
+style and format described below, shepherds the discussions in the
+appropriate forums, and attempts to build community consensus around
+the idea.  The PEP champion (a.k.a. Author) should first attempt to
+ascertain whether the idea is PEP-able.  Small enhancements or patches
+often don't need a PEP and can be injected into the Python development
+work flow with a patch submission to the SourceForge <a class="reference" href="http://sourceforge.net/tracker/?group_id=5470&amp;atid=305470">patch manager</a> <a class="footnote-reference" href="#id13" id="id14" name="id14">[6]</a>
+or <a class="reference" href="http://sourceforge.net/tracker/?atid=355470&amp;group_id=5470&amp;func=browse">feature request tracker</a> <a class="footnote-reference" href="#id16" id="id17" name="id17">[7]</a>.</p>
+<p>The PEP champion then emails the PEP editor &lt;<a class="reference" href="mailto:peps at python.org">peps at python.org</a>&gt; with a
+proposed title and a rough, but fleshed out, draft of the PEP.  This
+draft must be written in PEP style as described below.</p>
+<p>If the PEP editor approves, he will assign the PEP a number, label it
+as Standards Track or Informational, give it status "Draft", and
+create and check-in the initial draft of the PEP.  The PEP editor will
+not unreasonably deny a PEP.  Reasons for denying PEP status include
+duplication of effort, being technically unsound, not providing proper
+motivation or addressing backwards compatibility, or not in keeping
+with the Python philosophy.  The BDFL (Benevolent Dictator for Life,
+Guido van Rossum) can be consulted during the approval phase, and is
+the final arbitrator of the draft's PEP-ability.</p>
+<p>If a pre-PEP is rejected, the author may elect to take the pre-PEP to
+the comp.lang.python newsgroup (a.k.a. <a class="reference" href="mailto:python-list at python.org">python-list at python.org</a> mailing
+list) to help flesh it out, gain feedback and consensus from the
+community at large, and improve the PEP for re-submission.</p>
+<p>The author of the PEP is then responsible for posting the PEP to the
+community forums, and marshaling community support for it.  As updates
+are necessary, the PEP author can check in new versions if they have
+CVS commit permissions, or can email new PEP versions to the PEP
+editor for committing.</p>
+<p>Standards Track PEPs consists of two parts, a design document and a
+reference implementation.  The PEP should be reviewed and accepted
+before a reference implementation is begun, unless a reference
+implementation will aid people in studying the PEP.  Standards Track
+PEPs must include an implementation -- in the form of code, patch, or
+URL to same -- before it can be considered Final.</p>
+<p>PEP authors are responsible for collecting community feedback on a PEP
+before submitting it for review.  A PEP that has not been discussed on
+<a class="reference" href="mailto:python-list at python.org">python-list at python.org</a> and/or <a class="reference" href="mailto:python-dev at python.org">python-dev at python.org</a> will not be
+accepted.  However, wherever possible, long open-ended discussions on
+public mailing lists should be avoided.  Strategies to keep the
+discussions efficient include, setting up a separate SIG mailing list
+for the topic, having the PEP author accept private comments in the
+early design phases, etc.  PEP authors should use their discretion
+here.</p>
+<p>Once the authors have completed a PEP, they must inform the PEP editor
+that it is ready for review.  PEPs are reviewed by the BDFL and his
+chosen consultants, who may accept or reject a PEP or send it back to
+the author(s) for revision.  For a PEP that is pre-determined to be
+acceptable (e.g., it is an obvious win as-is and/or its implementation
+has already been checked in) the BDFL may also initiate a PEP review,
+first notifying the PEP author(s) and giving them a chance to make
+revisions.</p>
+<p>For a PEP to be accepted it must meet certain minimum criteria.  It
+must be a clear and complete description of the proposed enhancement.
+The enhancement must represent a net improvement.  The proposed
+implementation, if applicable, must be solid and must not complicate
+the interpreter unduly.  Finally, a proposed enhancement must be
+"pythonic" in order to be accepted by the BDFL.  (However, "pythonic"
+is an imprecise term; it may be defined as whatever is acceptable to
+the BDFL.  This logic is intentionally circular.)  See <a class="reference" href="http://www.python.org/peps/pep-0002.html">PEP 2</a> <a class="footnote-reference" href="#id9" id="id2" name="id2">[2]</a> for
+standard library module acceptance criteria.</p>
+<p>Once a PEP has been accepted, the reference implementation must be
+completed.  When the reference implementation is complete and accepted
+by the BDFL, the status will be changed to "Final".</p>
+<p>A PEP can also be assigned status "Deferred".  The PEP author or
+editor can assign the PEP this status when no progress is being made
+on the PEP.  Once a PEP is deferred, the PEP editor can re-assign it
+to draft status.</p>
+<p>A PEP can also be "Rejected".  Perhaps after all is said and done it
+was not a good idea.  It is still important to have a record of this
+fact.</p>
+<p>PEPs can also be replaced by a different PEP, rendering the original
+obsolete.  This is intended for Informational PEPs, where version 2 of
+an API can replace version 1.</p>
+<p>PEP work flow is as follows:</p>
+<pre class="literal-block">Draft -&gt; Accepted -&gt; Final -&gt; Replaced
+  ^
+  +----&gt; Rejected
+  v
+Deferred
+</pre>
+<p>Some Informational PEPs may also have a status of "Active" if they are
+never meant to be completed.  E.g. <a class="reference" href="http://www.python.org/peps/pep-0001.html">PEP 1</a> (this PEP).</p>
+</div>
+<div class="section" id="what-belongs-in-a-successful-pep">
+<h1><a class="toc-backref" href="#id30" name="what-belongs-in-a-successful-pep">What belongs in a successful PEP?</a></h1>
+<p>Each PEP should have the following parts:</p>
+<ol class="arabic">
+<li><p class="first">Preamble -- <a class="reference" href="http://www.faqs.org/rfcs/rfc822.html">RFC 822</a> style headers containing meta-data about the
+PEP, including the PEP number, a short descriptive title (limited
+to a maximum of 44 characters), the names, and optionally the
+contact info for each author, etc.</p>
+</li>
+<li><p class="first">Abstract -- a short (~200 word) description of the technical issue
+being addressed.</p>
+</li>
+<li><p class="first">Copyright/public domain -- Each PEP must either be explicitly
+labelled as placed in the public domain (see this PEP as an
+example) or licensed under the <a class="reference" href="http://www.opencontent.org/openpub/">Open Publication License</a> <a class="footnote-reference" href="#id18" id="id19" name="id19">[8]</a>.</p>
+</li>
+<li><p class="first">Specification -- The technical specification should describe the
+syntax and semantics of any new language feature.  The
+specification should be detailed enough to allow competing,
+interoperable implementations for any of the current Python
+platforms (CPython, Jython, Python .NET).</p>
+</li>
+<li><p class="first">Motivation -- The motivation is critical for PEPs that want to
+change the Python language.  It should clearly explain why the
+existing language specification is inadequate to address the
+problem that the PEP solves.  PEP submissions without sufficient
+motivation may be rejected outright.</p>
+</li>
+<li><p class="first">Rationale -- The rationale fleshes out the specification by
+describing what motivated the design and why particular design
+decisions were made.  It should describe alternate designs that
+were considered and related work, e.g. how the feature is supported
+in other languages.</p>
+<p>The rationale should provide evidence of consensus within the
+community and discuss important objections or concerns raised
+during discussion.</p>
+</li>
+<li><p class="first">Backwards Compatibility -- All PEPs that introduce backwards
+incompatibilities must include a section describing these
+incompatibilities and their severity.  The PEP must explain how the
+author proposes to deal with these incompatibilities.  PEP
+submissions without a sufficient backwards compatibility treatise
+may be rejected outright.</p>
+</li>
+<li><p class="first">Reference Implementation -- The reference implementation must be
+completed before any PEP is given status "Final", but it need not
+be completed before the PEP is accepted.  It is better to finish
+the specification and rationale first and reach consensus on it
+before writing code.</p>
+<p>The final implementation must include test code and documentation
+appropriate for either the Python language reference or the
+standard library reference.</p>
+</li>
+</ol>
+</div>
+<div class="section" id="pep-formats-and-templates">
+<h1><a class="toc-backref" href="#id31" name="pep-formats-and-templates">PEP Formats and Templates</a></h1>
+<p>There are two PEP formats available to authors: plaintext and
+<a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> <a class="footnote-reference" href="#id20" id="id21" name="id21">[9]</a>.</p>
+<p>Plaintext PEPs are written in plain ASCII text, contain minimal
+structural markup, and should adhere to a rigid style.  <a class="reference" href="http://www.python.org/peps/pep-0009.html">PEP 9</a> contains
+a boilerplate template <a class="footnote-reference" href="#id10" id="id3" name="id3">[3]</a> you can use to get started writing your
+plaintext PEP.</p>
+<p><a class="reference" href="http://docutils.sourceforge.net/rst.html">ReStructuredText</a> <a class="footnote-reference" href="#id20" id="id22" name="id22">[9]</a> PEPs allow for rich markup that is still quite easy
+to read, but results in much better-looking and more functional HTML.
+<a class="reference" href="http://www.python.org/peps/pep-0012.html">PEP 12</a> contains a boilerplate template <a class="footnote-reference" href="#id11" id="id4" name="id4">[4]</a> for use with
+reStructuredText PEPs.</p>
+<p>There is a Python script that converts both styles of PEPs to HTML for
+viewing on the web <a class="footnote-reference" href="#id12" id="id5" name="id5">[5]</a>.  Parsing and conversion of plaintext PEPs is
+self-contained within the script.  reStructuredText PEPs are parsed
+and converted by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> <a class="footnote-reference" href="#id23" id="id24" name="id24">[10]</a> code called from the script.</p>
+</div>
+<div class="section" id="pep-header-preamble">
+<h1><a class="toc-backref" href="#id32" name="pep-header-preamble">PEP Header Preamble</a></h1>
+<p>Each PEP must begin with an <a class="reference" href="http://www.faqs.org/rfcs/rfc822.html">RFC 822</a> style header preamble.  The headers
+must appear in the following order.  Headers marked with "*" are
+optional and are described below.  All other headers are required.</p>
+<pre class="literal-block">  PEP: &lt;pep number&gt;
+  Title: &lt;pep title&gt;
+  Version: &lt;cvs version string&gt;
+  Last-Modified: &lt;cvs date string&gt;
+  Author: &lt;list of authors' real names and optionally, email addrs&gt;
+* Discussions-To: &lt;email address&gt;
+  Status: &lt;Draft | Active | Accepted | Deferred | Rejected |
+           Final | Replaced&gt;
+  Type: &lt;Informational | Standards Track&gt;
+* Content-Type: &lt;text/plain | text/x-rst&gt;
+* Requires: &lt;pep numbers&gt;
+  Created: &lt;date created on, in dd-mmm-yyyy format&gt;
+* Python-Version: &lt;version number&gt;
+  Post-History: &lt;dates of postings to python-list and python-dev&gt;
+* Replaces: &lt;pep number&gt;
+* Replaced-By: &lt;pep number&gt;
+</pre>
+<p>The Author header lists the names, and optionally the email addresses
+of all the authors/owners of the PEP.  The format of the Author header
+value must be</p>
+<blockquote>
+Random J. User &lt;<a class="reference" href="mailto:address at dom.ain">address at dom.ain</a>&gt;</blockquote>
+<p>if the email address is included, and just</p>
+<blockquote>
+Random J. User</blockquote>
+<p>if the address is not given.  For historical reasons the format
+"<a class="reference" href="mailto:address at dom.ain">address at dom.ain</a> (Random J. User)" may appear in a PEP, however new
+PEPs must use the mandated format above, and it is acceptable to
+change to this format when PEPs are updated.</p>
+<p>If there are multiple authors, each should be on a separate line
+following <a class="reference" href="http://www.faqs.org/rfcs/rfc2822.html">RFC 2822</a> continuation line conventions.  Note that personal
+email addresses in PEPs will be obscured as a defense against spam
+harvesters.</p>
+<p>While a PEP is in private discussions (usually during the initial
+Draft phase), a Discussions-To header will indicate the mailing list
+or URL where the PEP is being discussed.  No Discussions-To header is
+necessary if the PEP is being discussed privately with the author, or
+on the python-list or python-dev email mailing lists.  Note that email
+addresses in the Discussions-To header will not be obscured.</p>
+<p>The Type header specifies the type of PEP: Informational or Standards
+Track.</p>
+<p>The format of a PEP is specified with a Content-Type header.  The
+acceptable values are "text/plain" for plaintext PEPs (see <a class="reference" href="http://www.python.org/peps/pep-0009.html">PEP 9</a> <a class="footnote-reference" href="#id10" id="id6" name="id6">[3]</a>)
+and "text/x-rst" for reStructuredText PEPs (see <a class="reference" href="http://www.python.org/peps/pep-0012.html">PEP 12</a> <a class="footnote-reference" href="#id11" id="id7" name="id7">[4]</a>).
+Plaintext ("text/plain") is the default if no Content-Type header is
+present.</p>
+<p>The Created header records the date that the PEP was assigned a
+number, while Post-History is used to record the dates of when new
+versions of the PEP are posted to python-list and/or python-dev.  Both
+headers should be in dd-mmm-yyyy format, e.g. 14-Aug-2001.</p>
+<p>Standards Track PEPs must have a Python-Version header which indicates
+the version of Python that the feature will be released with.
+Informational PEPs do not need a Python-Version header.</p>
+<p>PEPs may have a Requires header, indicating the PEP numbers that this
+PEP depends on.</p>
+<p>PEPs may also have a Replaced-By header indicating that a PEP has been
+rendered obsolete by a later document; the value is the number of the
+PEP that replaces the current document.  The newer PEP must have a
+Replaces header containing the number of the PEP that it rendered
+obsolete.</p>
+</div>
+<div class="section" id="reporting-pep-bugs-or-submitting-pep-updates">
+<h1><a class="toc-backref" href="#id33" name="reporting-pep-bugs-or-submitting-pep-updates">Reporting PEP Bugs, or Submitting PEP Updates</a></h1>
+<p>How you report a bug, or submit a PEP update depends on several
+factors, such as the maturity of the PEP, the preferences of the PEP
+author, and the nature of your comments.  For the early draft stages
+of the PEP, it's probably best to send your comments and changes
+directly to the PEP author.  For more mature, or finished PEPs you may
+want to submit corrections to the SourceForge <a class="reference" href="http://sourceforge.net/tracker/?group_id=5470&amp;atid=105470">bug manager</a> <a class="footnote-reference" href="#id25" id="id26" name="id26">[11]</a> or better
+yet, the SourceForge <a class="reference" href="http://sourceforge.net/tracker/?group_id=5470&amp;atid=305470">patch manager</a> <a class="footnote-reference" href="#id13" id="id15" name="id15">[6]</a> so that your changes don't get
+lost.  If the PEP author is a SF developer, assign the bug/patch to
+him, otherwise assign it to the PEP editor.</p>
+<p>When in doubt about where to send your changes, please check first
+with the PEP author and/or PEP editor.</p>
+<p>PEP authors who are also SF committers, can update the PEPs themselves
+by using "cvs commit" to commit their changes.  Remember to also push
+the formatted PEP text out to the web by doing the following:</p>
+<pre class="literal-block">% python pep2html.py -i NUM
+</pre>
+<p>where NUM is the number of the PEP you want to push out.  See</p>
+<pre class="literal-block">% python pep2html.py --help
+</pre>
+<p>for details.</p>
+</div>
+<div class="section" id="transferring-pep-ownership">
+<h1><a class="toc-backref" href="#id34" name="transferring-pep-ownership">Transferring PEP Ownership</a></h1>
+<p>It occasionally becomes necessary to transfer ownership of PEPs to a
+new champion.  In general, we'd like to retain the original author as
+a co-author of the transferred PEP, but that's really up to the
+original author.  A good reason to transfer ownership is because the
+original author no longer has the time or interest in updating it or
+following through with the PEP process, or has fallen off the face of
+the 'net (i.e. is unreachable or not responding to email).  A bad
+reason to transfer ownership is because you don't agree with the
+direction of the PEP.  We try to build consensus around a PEP, but if
+that's not possible, you can always submit a competing PEP.</p>
+<p>If you are interested in assuming ownership of a PEP, send a message
+asking to take over, addressed to both the original author and the PEP
+editor &lt;<a class="reference" href="mailto:peps at python.org">peps at python.org</a>&gt;.  If the original author doesn't respond to
+email in a timely manner, the PEP editor will make a unilateral
+decision (it's not like such decisions can't be reversed :).</p>
+</div>
+<div class="section" id="references-and-footnotes">
+<h1><a class="toc-backref" href="#id35" name="references-and-footnotes">References and Footnotes</a></h1>
+<table class="footnote" frame="void" id="id8" rules="none">
+<colgroup><col class="label"><col></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="id8">[1]</a></td><td>This historical record is available by the normal CVS commands
+for retrieving older revisions.  For those without direct access to
+the CVS tree, you can browse the current and past PEP revisions via
+the SourceForge web site at
+<a class="reference" href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/peps/">http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/peps/</a></td></tr>
+</tbody>
+</table>
+<table class="footnote" frame="void" id="id9" rules="none">
+<colgroup><col class="label"><col></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="id9">[2]</a></td><td><a class="reference" href="http://www.python.org/peps/pep-0002.html">PEP 2</a>, Procedure for Adding New Modules, Faassen
+(<a class="reference" href="http://www.python.org/peps/pep-0002.html">http://www.python.org/peps/pep-0002.html</a>)</td></tr>
+</tbody>
+</table>
+<table class="footnote" frame="void" id="id10" rules="none">
+<colgroup><col class="label"><col></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id10">[3]</a></td><td><em>(<a class="fn-backref" href="#id3">1</a>, <a class="fn-backref" href="#id6">2</a>)</em> <a class="reference" href="http://www.python.org/peps/pep-0009.html">PEP 9</a>, Sample Plaintext PEP Template, Warsaw
+(<a class="reference" href="http://www.python.org/peps/pep-0009.html">http://www.python.org/peps/pep-0009.html</a>)</td></tr>
+</tbody>
+</table>
+<table class="footnote" frame="void" id="id11" rules="none">
+<colgroup><col class="label"><col></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id11">[4]</a></td><td><em>(<a class="fn-backref" href="#id4">1</a>, <a class="fn-backref" href="#id7">2</a>)</em> <a class="reference" href="http://www.python.org/peps/pep-0012.html">PEP 12</a>, Sample reStructuredText PEP Template, Goodger, Warsaw
+(<a class="reference" href="http://www.python.org/peps/pep-0012.html">http://www.python.org/peps/pep-0012.html</a>)</td></tr>
+</tbody>
+</table>
+<table class="footnote" frame="void" id="id12" rules="none">
+<colgroup><col class="label"><col></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id5" name="id12">[5]</a></td><td>The script referred to here is pep2html.py, which lives in the
+same directory in the CVS tree as the PEPs themselves.  Try
+<tt class="literal"><span class="pre">pep2html.py</span> <span class="pre">--help</span></tt> for details.  The URL for viewing PEPs on
+the web is <a class="reference" href="http://www.python.org/peps/">http://www.python.org/peps/</a>.</td></tr>
+</tbody>
+</table>
+<table class="footnote" frame="void" id="id13" rules="none">
+<colgroup><col class="label"><col></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id13">[6]</a></td><td><em>(<a class="fn-backref" href="#id14">1</a>, <a class="fn-backref" href="#id15">2</a>)</em> <a class="reference" href="http://sourceforge.net/tracker/?group_id=5470&amp;atid=305470">http://sourceforge.net/tracker/?group_id=5470&amp;atid=305470</a></td></tr>
+</tbody>
+</table>
+<table class="footnote" frame="void" id="id16" rules="none">
+<colgroup><col class="label"><col></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id17" name="id16">[7]</a></td><td><a class="reference" href="http://sourceforge.net/tracker/?atid=355470&amp;group_id=5470&amp;func=browse">http://sourceforge.net/tracker/?atid=355470&amp;group_id=5470&amp;func=browse</a></td></tr>
+</tbody>
+</table>
+<table class="footnote" frame="void" id="id18" rules="none">
+<colgroup><col class="label"><col></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id19" name="id18">[8]</a></td><td><a class="reference" href="http://www.opencontent.org/openpub/">http://www.opencontent.org/openpub/</a></td></tr>
+</tbody>
+</table>
+<table class="footnote" frame="void" id="id20" rules="none">
+<colgroup><col class="label"><col></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id20">[9]</a></td><td><em>(<a class="fn-backref" href="#id21">1</a>, <a class="fn-backref" href="#id22">2</a>)</em> <a class="reference" href="http://docutils.sourceforge.net/rst.html">http://docutils.sourceforge.net/rst.html</a></td></tr>
+</tbody>
+</table>
+<table class="footnote" frame="void" id="id23" rules="none">
+<colgroup><col class="label"><col></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id24" name="id23">[10]</a></td><td><a class="reference" href="http://docutils.sourceforge.net/">http://docutils.sourceforge.net/</a></td></tr>
+</tbody>
+</table>
+<table class="footnote" frame="void" id="id25" rules="none">
+<colgroup><col class="label"><col></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id26" name="id25">[11]</a></td><td><a class="reference" href="http://sourceforge.net/tracker/?group_id=5470&amp;atid=105470">http://sourceforge.net/tracker/?group_id=5470&amp;atid=105470</a></td></tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="copyright">
+<h1><a class="toc-backref" href="#id36" name="copyright">Copyright</a></h1>
+<p>This document has been placed in the public domain.</p>
+<!-- Local Variables:
+mode: indented-text
+indent-tabs-mode: nil
+sentence-end-double-space: t
+fill-column: 70
+End: -->
+</div>
+</div>
+
+<hr class="footer">
+<div class="footer">
+<a class="reference" href="http://www.python.org/peps/pep-0001.txt">View document source</a>.
+Generated on: 2003-09-22 04:52 UTC.
+Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
+</div>
+</body></html>
\ No newline at end of file

Added: pypy/trunk/doc/funding/pep-0001/pep-0001.sxw
==============================================================================
Binary file. No diff available.

Added: pypy/trunk/doc/funding/pep-0001/pep-0001_files/PyBanner046.gif
==============================================================================
Binary file. No diff available.

Added: pypy/trunk/doc/funding/pep-0001/pep-0001_files/pep.css
==============================================================================
--- (empty file)
+++ pypy/trunk/doc/funding/pep-0001/pep-0001_files/pep.css	Tue Oct 14 20:56:30 2003
@@ -0,0 +1,240 @@
+/*
+:Author: David Goodger
+:Contact: goodger at users.sourceforge.net
+:date: $Date: 2002/11/12 03:06:36 $
+:version: $Revision: 1.5 $
+:copyright: This stylesheet has been placed in the public domain.
+
+Default cascading style sheet for the PEP HTML output of Docutils.
+*/
+
+.first {
+  margin-top: 0 }
+
+.last {
+  margin-bottom: 0 }
+
+.navigation {
+  width: 100% ;
+  background: #99ccff ;
+  margin-top: 0px ;
+  margin-bottom: 0px }
+
+.navigation .navicon {
+  width: 150px ;
+  height: 35px }
+
+.navigation .textlinks {
+  padding-left: 1em ;
+  text-align: left }
+
+.navigation td, .navigation th {
+  padding-left: 0em ;
+  padding-right: 0em ;
+  vertical-align: middle }
+
+.rfc2822 {
+  margin-top: 0.5em ;
+  margin-left: 0.5em ;
+  margin-right: 0.5em ;
+  margin-bottom: 0em }
+
+.rfc2822 td {
+  text-align: left }
+
+.rfc2822 th.field-name {
+  text-align: right ;
+  font-family: sans-serif ;
+  padding-right: 0.5em ;
+  font-weight: bold ;
+  margin-bottom: 0em }
+
+a.toc-backref {
+  text-decoration: none ;
+  color: black }
+
+body {
+  margin: 0px ;
+  margin-bottom: 1em ;
+  padding: 0px }
+
+dd {
+  margin-bottom: 0.5em }
+
+div.section {
+  margin-left: 1em ;
+  margin-right: 1em ;
+  margin-bottom: 1.5em }
+
+div.section div.section {
+  margin-left: 0em ;
+  margin-right: 0em ;
+  margin-top: 1.5em }
+
+div.abstract {
+  margin: 2em 5em }
+
+div.abstract p.topic-title {
+  font-weight: bold ;
+  text-align: center }
+
+div.attention, div.caution, div.danger, div.error, div.hint,
+div.important, div.note, div.tip, div.warning {
+  margin: 2em ;
+  border: medium outset ;
+  padding: 1em }
+
+div.attention p.admonition-title, div.caution p.admonition-title,
+div.danger p.admonition-title, div.error p.admonition-title,
+div.warning p.admonition-title {
+  color: red ;
+  font-weight: bold ;
+  font-family: sans-serif }
+
+div.hint p.admonition-title, div.important p.admonition-title,
+div.note p.admonition-title, div.tip p.admonition-title {
+  font-weight: bold ;
+  font-family: sans-serif }
+
+div.figure {
+  margin-left: 2em }
+
+div.footer, div.header {
+  font-size: smaller }
+
+div.footer {
+  margin-left: 1em ;
+  margin-right: 1em }
+
+div.system-messages {
+  margin: 5em }
+
+div.system-messages h1 {
+  color: red }
+
+div.system-message {
+  border: medium outset ;
+  padding: 1em }
+
+div.system-message p.system-message-title {
+  color: red ;
+  font-weight: bold }
+
+div.topic {
+  margin: 2em }
+
+h1 {
+  font-family: sans-serif ;
+  font-size: large }
+
+h2 {
+  font-family: sans-serif ;
+  font-size: medium }
+
+h3 {
+  font-family: sans-serif ;
+  font-size: small }
+
+h4 {
+  font-family: sans-serif ;
+  font-style: italic ;
+  font-size: small }
+
+h5 {
+  font-family: sans-serif;
+  font-size: x-small }
+
+h6 {
+  font-family: sans-serif;
+  font-style: italic ;
+  font-size: x-small }
+
+.section hr {
+  width: 75% }
+
+ol.simple, ul.simple {
+  margin-bottom: 1em }
+
+ol.arabic {
+  list-style: decimal }
+
+ol.loweralpha {
+  list-style: lower-alpha }
+
+ol.upperalpha {
+  list-style: upper-alpha }
+
+ol.lowerroman {
+  list-style: lower-roman }
+
+ol.upperroman {
+  list-style: upper-roman }
+
+p.caption {
+  font-style: italic }
+
+p.credits {
+  font-style: italic ;
+  font-size: smaller }
+
+p.label {
+  white-space: nowrap }
+
+p.topic-title {
+  font-family: sans-serif ;
+  font-weight: bold }
+
+pre.line-block {
+  font-family: serif ;
+  font-size: 100% }
+
+pre.literal-block, pre.doctest-block {
+  margin-left: 2em ;
+  margin-right: 2em ;
+  background-color: #eeeeee }
+
+span.classifier {
+  font-family: sans-serif ;
+  font-style: oblique }
+
+span.classifier-delimiter {
+  font-family: sans-serif ;
+  font-weight: bold }
+
+span.interpreted {
+  font-family: sans-serif }
+
+span.option-argument {
+  font-style: italic }
+
+span.pre {
+  white-space: pre }
+
+span.problematic {
+  color: red }
+
+table {
+  margin-top: 0.5em ;
+  margin-bottom: 0.5em }
+
+td, th {
+  padding-left: 0.5em ;
+  padding-right: 0.5em ;
+  vertical-align: top }
+
+td.num {
+  text-align: right }
+
+th.field-name {
+  font-weight: bold ;
+  text-align: left ;
+  white-space: nowrap }
+
+h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
+  font-size: 100% }
+
+tt {
+  background-color: #eeeeee }
+
+ul.auto-toc {
+  list-style-type: none }


More information about the Pypy-commit mailing list