Use new acceptable practices for PEP references.

This commit is contained in:
Barry Warsaw 2001-07-05 19:20:16 +00:00
parent bea68c0534
commit 786551c3db
10 changed files with 64 additions and 41 deletions

View File

@ -60,7 +60,7 @@ The rational() Builtin
References
[1] PEP 240, Adding a Rational Literal to Python, Zadka,
http://python.sourceforge.net/peps/pep-0240.html
http://www.python.org/peps/pep-0240.html
Copyright

View File

@ -64,7 +64,7 @@ Common Objections
References
[1] PEP 239, Adding a Rational Type to Python, Zadka,
http://python.sourceforge.net/peps/pep-0239.html
http://www.python.org/peps/pep-0239.html
Copyright

View File

@ -162,7 +162,7 @@ Status
References
[1] Metadata for Python Software Package, Kuchling,
http://python.sourceforge.net/peps/pep-0241.html
http://www.python.org/peps/pep-0241.html
[2] RFC 1867, Form-based File Upload in HTML
http://www.faqs.org/rfcs/rfc1867.html

View File

@ -18,12 +18,12 @@ Motivation
of improving the language over the long term, over the short term
it's contentious and disrupting.
The "Guidelines for Language Evolution" PEP [1] suggests ways to
ease the pain, and this PEP introduces some machinery in support
of that.
PEP 1, Guidelines for Language Evolution[1] suggests ways to ease
the pain, and this PEP introduces some machinery in support of
that.
The "Statically Nested Scopes" PEP [2] is the first application,
and will be used as an example here.
PEP 2, Statically Nested Scopes[2] is the first application, and
will be used as an example here.
When a new, potentially incompatible language feature is added,
some modules and libraries may chose to use it, while others may
@ -37,11 +37,12 @@ Motivation
- those that are designed to eventually become the only option, at
which time specifying use of them is not necessary anymore. The
features for which the syntax of the "Back to the __future__"
PEP [3] was proposed fall into this category. This PEP supports
declaring such features, and supports phasing out the "old"
meaning of constructs whose semantics has changed under the new
feature. However, it defines no policy as to what features must
be phased out eventually.
PEP 236, Back to the __future__[3] was proposed fall into this
category. This PEP supports declaring such features, and
supports phasing out the "old" meaning of constructs whose
semantics has changed under the new feature. However, it
defines no policy as to what features must be phased out
eventually.
- those which are designed to stay optional forever, e.g. if they
change some default setting in the interpreter. An example for
@ -150,11 +151,14 @@ Questions and Answers
References and Footnotes
[1] http://python.sourceforge.net/peps/pep-0005.html
[1] PEP 5, Guidelines for Language Evolution, Prescod
http://www.python.org/peps/pep-0005.html
[2] http://python.sourceforge.net/peps/pep-0227.html
[2] PEP 227, Statically Nested Scopes, Hylton
http://www.python.org/peps/pep-0227.html
[3] http://python.sourceforge.net/peps/pep-0236.html
[3] PEP 236, Back to the __future__, Peters
http://www.python.org/peps/pep-0236.html
Copyright

View File

@ -468,18 +468,18 @@ References
[2] http://www.zope.org
[3] PEP 232, Function Attributes, Warsaw
http://python.sourceforge.net/peps/pep-0232.html
http://www.python.org/peps/pep-0232.html
[4] PEP 233, Python Online Help, Prescod
http://python.sourceforge.net/peps/pep-0233.html
http://www.python.org/peps/pep-0233.html
[5] http://www.lemburg.com/files/python/mxProxy.html
[6] PEP 236, Back to the __future__, Peters
http://python.sourceforge.net/peps/pep-0236.html
http://www.python.org/peps/pep-0236.html
[7] PEP 230, Warning Framework, van Rossum
http://python.sourceforge.net/peps/pep-0236.html
http://www.python.org/peps/pep-0236.html
Copyright

View File

@ -531,7 +531,7 @@ References and Footnotes
[8] http://mail.python.org/pipermail/python-list/2001-March/035197.html
[9] PEP 234, Iterators, Yee
[9] PEP 234, Iterators, Yee, Van Rossum
http://www.python.org/peps/pep-0234.txt

View File

@ -451,17 +451,27 @@ Reference Implementation
Footnotes and References
[1] PEP 234, http://python.sf.net/peps/pep-0234.html
[1] PEP 234, Iterators, Yee, Van Rossum
http://www.python.org/peps/pep-0234.html
[2] http://www.stackless.com/
[3] PEP 219, http://python.sf.net/peps/pep-0219.html
[3] PEP 219, Stackless Python, McMillan
http://www.python.org/peps/pep-0219.html
[4] "Iteration Abstraction in Sather"
Murer , Omohundro, Stoutamire and Szyperski
http://www.icsi.berkeley.edu/~sather/Publications/toplas.html
[5] http://www.cs.arizona.edu/icon/
[6] The concept of iterators is described in PEP 234
http://python.sf.net/peps/pep-0234.html
[6] The concept of iterators is described in PEP 234. See [1] above.
[7] http://python.ca/nas/python/generator.diff
[8] http://python.sf.net/peps/pep-0236.html
[8] PEP 236, Back to the __future__, Peters
http://www.python.org/peps/pep-0236.html
[9] To experiment with this implementation, check out Python from CVS
according to the instructions at
http://sf.net/cvs/?group_id=5470

View File

@ -182,7 +182,7 @@ Specification
- First line is a one-line synopsis.
PEP 257, "Docstring Conventions" [12], documents these issues.
PEP 257, Docstring Conventions[12], documents these issues.
2. Docstring processing system generic implementation details.
Documents issues such as:
@ -205,8 +205,8 @@ Specification
- Output management.
These issues are applicable to any docstring processing system
implementation. PEP 258, "DPS Generic Implementation Details"
[13], documents these issues.
implementation. PEP 258, DPS Generic Implementation
Details[13], documents these issues.
3. Docstring processing system implementation.
@ -263,7 +263,8 @@ Project Web Site
References and Footnotes
[1] http://python.sf.net/peps/pep-0216.html
[1] PEP 236, Docstring Format, Zadka
http://www.python.org/peps/pep-0216.html
[2] http://www.literateprogramming.com/
@ -285,9 +286,11 @@ References and Footnotes
[11] http://dev.zope.org/Members/jim/StructuredTextWiki/FrontPage/
[12] http://python.sf.net/peps/pep-0257.html
[12] PEP 257, Docstring Conventions, Goodger, Van Rossum
http://www.python.org/peps/pep-0257.html
[13] http://python.sf.net/peps/pep-0258.html
[13] PEP 258, DPS Generic Implementation Details, Goodger
http://www.python.org/peps/pep-0258.html
Copyright
@ -297,9 +300,9 @@ Copyright
Acknowledgements
This document borrows text from PEP 216 "Docstring Format" by
Moshe Zadka [1]. It is intended as a reorganization of PEP 216
and its approach.
This document borrows text from PEP 216, Docstring Format by Moshe
Zadka[1]. It is intended as a reorganization of PEP 216 and its
approach.
This document also borrows ideas from the archives of the Python
Doc-SIG. Thanks to all members past & present.

View File

@ -205,14 +205,17 @@ Specification
References and Footnotes
[1] http://python.sf.net/peps/pep-0256.html
[1] PEP 256, Docstring Processing System Framework, Goodger
http://www.python.org/peps/pep-0256.html
[2] http://python.sf.net/peps/pep-0258.html
[2] PEP 258, DPS Generic Implementation Details, Goodger
http://www.python.org/peps/pep-0258.html
[3] Guido van Rossum, Python's creator and Benevolent Dictator For
Life.
[4] http://www.python.org/doc/essays/styleguide.html
[4] PEP 8, Style Guide for Python Code, van Rossum, Warsaw
http://www.python.org/peps/pep-0008.html
[5] http://www.python.org/sigs/doc-sig/

View File

@ -312,13 +312,16 @@ Specification
References and Footnotes
[1] http://python.sf.net/peps/pep-0256.html
[1] PEP 256, Docstring Processing System Framework, Goodger
http://www.python.org/peps/pep-0256.html
[2] http://www.python.org/sigs/doc-sig/
[3] http://python.sf.net/peps/pep-0224.html
[3] PEP 224, Attribute Docstrings, Lemburg
http://www.python.org/peps/pep-0224.html
[4] http://python.sf.net/peps/pep-0257.html
[4] PEP 257, Docstring Conventions, Goodger, Van Rossum
http://www.python.org/peps/pep-0257.html
[5] http://www.rfc-editor.org/rfc/rfc1766.txt