Use new acceptable practices for PEP references.
This commit is contained in:
parent
96eb7ba974
commit
bea68c0534
|
@ -331,9 +331,11 @@ Copyright
|
|||
References
|
||||
|
||||
[1] http://www.python.org/pipermail/python-list/2000-June/059556.html
|
||||
|
||||
[2] http://sourceforge.net/patch?func=detailpatch&patch_id=100699&group_id=5470
|
||||
[3] PEP 211, Adding New Linear Algebra Operators,
|
||||
http://python.sourceforge.net/peps/pep-0211.html
|
||||
|
||||
[3] PEP 211, Adding A New Outer Product Operator, Wilson
|
||||
http://www.python.org/peps/pep-0211.html
|
||||
|
||||
|
||||
|
||||
|
|
18
pep-0211.txt
18
pep-0211.txt
|
@ -71,9 +71,9 @@ Background
|
|||
Iterators
|
||||
|
||||
The planned addition of iterators to Python 2.2 opens up a broader
|
||||
scope for this proposal. As part of the discussion of PEP 0201
|
||||
"Lockstep Iteration" [4], the author of this proposal conducted an
|
||||
informal usability experiment [5]. The results showed that users
|
||||
scope for this proposal. As part of the discussion of PEP 201,
|
||||
Lockstep Iteration[4], the author of this proposal conducted an
|
||||
informal usability experiment[5]. The results showed that users
|
||||
are psychologically receptive to "cross-product" loop syntax. For
|
||||
example, most users expected:
|
||||
|
||||
|
@ -155,7 +155,7 @@ Alternatives
|
|||
expression of a very common idiom (nested loops).
|
||||
|
||||
3. Introduce prefixed forms of all existing operators, such as
|
||||
"~*" and "~+", as proposed in PEP 0225 [1].
|
||||
"~*" and "~+", as proposed in PEP 225 [1].
|
||||
|
||||
Our objections to this are that there isn't enough demand to
|
||||
justify the additional complexity (see Rawlings' comments [3]),
|
||||
|
@ -172,10 +172,16 @@ Acknowledgments
|
|||
|
||||
References
|
||||
|
||||
[1] http://python.sourceforge.net/peps/pep-0225.html
|
||||
[1] PEP 225, Elementwise/Objectwise Operators, Zhu, Lielens
|
||||
http://www.python.org/peps/pep-0225.html
|
||||
|
||||
[2] http://bevo.che.wisc.edu/octave/
|
||||
|
||||
[3] http://www.egroups.com/message/python-numeric/4
|
||||
[4] http://python.sourceforge.net/peps/pep-0201.html
|
||||
|
||||
[4] PEP 201, Lockstep Iteration, Warsaw
|
||||
http://www.python.org/peps/pep-0201.html
|
||||
|
||||
[5] http://mail.python.org/pipermail/python-dev/2000-July/006427.html
|
||||
|
||||
|
||||
|
|
|
@ -760,13 +760,13 @@ Credits and archives
|
|||
http://www.python.org/pipermail/python-list/2000-August/112529.html
|
||||
http://www.python.org/pipermail/python-dev/2000-August/014906.html
|
||||
|
||||
There is an alternative PEP (with official PEP number 211) by Greg
|
||||
Wilson, titled "Adding New Linear Algebra Operators to Python".
|
||||
There is an alternative PEP (officially, PEP 211) by Greg Wilson,
|
||||
titled "Adding New Linear Algebra Operators to Python".
|
||||
|
||||
Its first (and current) version is at:
|
||||
|
||||
http://www.python.org/pipermail/python-dev/2000-August/014876.html
|
||||
http://python.sourceforge.net/peps/pep-0211.html
|
||||
http://www.python.org/peps/pep-0211.html
|
||||
|
||||
|
||||
Additional References
|
||||
|
|
|
@ -599,7 +599,8 @@ References
|
|||
[6] http://www.python.org/doc/essays/metaclasses/
|
||||
[7] http://www.foretec.com/python/workshops/1998-11/dd-ascher-sum.html
|
||||
[8] http://www.python.org/doc/howto/rexec/rexec.html
|
||||
[9] http://python.sourceforge.net/peps/pep-0213.html
|
||||
[9] PEP 213, Attribute Access Handlers, Prescod
|
||||
http://www.python.org/peps/pep-0213.html
|
||||
|
||||
|
||||
Rejection
|
||||
|
|
23
pep-0236.txt
23
pep-0236.txt
|
@ -18,16 +18,16 @@ Motivation
|
|||
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
|
||||
PEP 5, 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
|
||||
PEP 227, Statically Nested Scopes[2] is the first application, and
|
||||
will be used as an example here.
|
||||
|
||||
|
||||
Intent
|
||||
|
||||
[Note: This is policy, and so should eventually move into PEP 5[1]]
|
||||
[Note: This is policy, and so should eventually move into PEP 5 [1]]
|
||||
|
||||
When an incompatible change to core language syntax or semantics is
|
||||
being made:
|
||||
|
@ -38,9 +38,9 @@ Intent
|
|||
2. A future release R is identified in which the new syntax or semantics
|
||||
will be enforced.
|
||||
|
||||
3. The mechanisms described in the "Warning Framework" PEP [3] are used
|
||||
to generate warnings, whenever possible, about constructs or
|
||||
operations whose meaning may[4] change in release R.
|
||||
3. The mechanisms described in PEP 3, Warning Framework[3] are
|
||||
used to generate warnings, whenever possible, about constructs
|
||||
or operations whose meaning may[4] change in release R.
|
||||
|
||||
4. The new future_statement (see below) can be explicitly included in a
|
||||
module M to request that the code in module M use the new syntax or
|
||||
|
@ -280,7 +280,7 @@ Questions and Answers
|
|||
Q: What about incompatibilites due to changes in the Python virtual
|
||||
machine?
|
||||
|
||||
A: Outside the scope of this PEP, although PEP 5[1] suggests a grace
|
||||
A: Outside the scope of this PEP, although PEP 5 [1] suggests a grace
|
||||
period there too, and the future_statement may also have a role to
|
||||
play there.
|
||||
|
||||
|
@ -337,11 +337,14 @@ Copyright
|
|||
|
||||
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-0230.html
|
||||
[3] PEP 230, Warning Framework, Van Rossum
|
||||
http://www.python.org/peps/pep-0230.html
|
||||
|
||||
[4] Note that this is "may" and not "will": better safe than sorry. Of
|
||||
course spurious warnings won't be generated when avoidable with
|
||||
|
|
|
@ -51,7 +51,7 @@ Rationale
|
|||
Changing the Semantics of the / Operator
|
||||
|
||||
The nb_divide slot on integers (and long integers, if these are a
|
||||
separate type, but see PEP 237[1]) will issue a warning when given
|
||||
separate type, but see PEP 237 [1]) will issue a warning when given
|
||||
integers a and b such that
|
||||
|
||||
a % b != 0
|
||||
|
@ -94,13 +94,13 @@ Open Issues
|
|||
References
|
||||
|
||||
[1] PEP 237, Unifying Long Integers and Integers, Zadka,
|
||||
http://python.sourceforge.net/peps/pep-0237.html
|
||||
http://www.python.org/peps/pep-0237.html
|
||||
|
||||
[2] 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
|
||||
|
||||
[3] 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
|
||||
|
|
Loading…
Reference in New Issue