Skip to content

Commit 1c2770d

Browse files
authored
PEP 3131: Fix links (#4263)
* PEP 3131: Replace 404 with Internet Archive link * PEP 3131: Use https * PEP 3131: Move references inline
1 parent 2b95453 commit 1c2770d

1 file changed

Lines changed: 19 additions & 23 deletions

File tree

peps/pep-3131.rst

Lines changed: 19 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -57,8 +57,9 @@ an additional policy is necessary, anyway.
5757
Specification of Language Changes
5858
=================================
5959

60-
The syntax of identifiers in Python will be based on the Unicode standard annex
61-
UAX-31 [1]_, with elaboration and changes as defined below.
60+
The syntax of identifiers in Python will be based on the `Unicode standard annex
61+
UAX-31 <https://www.unicode.org/reports/tr31/>`__, with elaboration and changes
62+
as defined below.
6263

6364
Within the ASCII range (U+0001..U+007F), the valid characters for identifiers
6465
are the same as in Python 2.5. This specification only introduces additional
@@ -69,9 +70,10 @@ the ``unicodedata`` module.
6970
The identifier syntax is ``<XID_Start> <XID_Continue>*``.
7071

7172
The exact specification of what characters have the XID_Start or
72-
XID_Continue properties can be found in the DerivedCoreProperties
73-
file of the Unicode data in use by Python (4.1 at the time this
74-
PEP was written), see [6]_. For reference, the construction rules
73+
XID_Continue properties can be found in the `DerivedCoreProperties
74+
file <https://www.unicode.org/Public/4.1.0/ucd/DerivedCoreProperties.txt>`__
75+
of the Unicode data in use by Python (4.1 at the time this
76+
PEP was written). For reference, the construction rules
7577
for these sets are given below. The XID_* properties are derived
7678
from ID_Start/ID_Continue, which are derived themselves.
7779

@@ -94,7 +96,7 @@ comparison of identifiers is based on NFKC.
9496

9597
A non-normative HTML file listing all valid identifier characters for
9698
Unicode 4.1 can be found at
97-
http://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html.
99+
https://web.archive.org/web/20081016132748/http://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html.
98100

99101
Policy Specification
100102
====================
@@ -136,8 +138,9 @@ The following changes will need to be made to the parser:
136138
Open Issues
137139
===========
138140

139-
John Nagle suggested consideration of Unicode Technical Standard #39,
140-
[2]_, which discusses security mechanisms for Unicode identifiers.
141+
John Nagle suggested consideration of `Unicode Technical Standard #39
142+
<https://www.unicode.org/reports/tr39/>`__,
143+
which discusses security mechanisms for Unicode identifiers.
141144
It's not clear how that can precisely apply to this PEP; possible
142145
consequences are
143146

@@ -153,7 +156,8 @@ needs two identifiers to compare them for confusion - is it possible
153156
to somehow apply it to a single identifier only, and warn?
154157

155158
In follow-up discussion, it turns out that John Nagle actually
156-
meant to suggest UTR#36, level "Highly Restrictive", [3]_.
159+
meant to suggest `UTR#36 <https://www.unicode.org/reports/tr36/>`__,
160+
level "Highly Restrictive".
157161

158162
Several people suggested to allow and ignore formatting control
159163
characters (general category Cf), as is done in Java, JavaScript, and
@@ -164,15 +168,17 @@ later.
164168
Some people would like to see an option on selecting support
165169
for this PEP at run-time; opinions vary on what precisely
166170
that option should be, and what precisely its default value
167-
should be. Guido van Rossum commented in [5]_ that a global
168-
flag passed to the interpreter is not acceptable, as it would
171+
should be. `Guido van Rossum commented
172+
<https://mail.python.org/pipermail/python-3000/2007-May/007925.html>`__
173+
that a global flag passed to the interpreter is not acceptable, as it would
169174
apply to all modules.
170175

171176
Discussion
172177
==========
173178

174-
Ka-Ping Yee summarizes discussion and further objection
175-
in [4]_ as such:
179+
`Ka-Ping Yee summarizes discussion and further objection
180+
<https://mail.python.org/pipermail/python-3000/2007-June/008161.html>`__
181+
as such:
176182

177183
A. Should identifiers be allowed to contain any Unicode letter?
178184

@@ -250,16 +256,6 @@ F. Which normalization form should be used, NFC or NFKC?
250256
G. Should source code be required to be in normalized form?
251257

252258

253-
References
254-
==========
255-
256-
.. [1] http://www.unicode.org/reports/tr31/
257-
.. [2] http://www.unicode.org/reports/tr39/
258-
.. [3] http://www.unicode.org/reports/tr36/
259-
.. [4] https://mail.python.org/pipermail/python-3000/2007-June/008161.html
260-
.. [5] https://mail.python.org/pipermail/python-3000/2007-May/007925.html
261-
.. [6] http://www.unicode.org/Public/4.1.0/ucd/DerivedCoreProperties.txt
262-
263259
Copyright
264260
=========
265261

0 commit comments

Comments
 (0)