Many PEPs: Resolve reference warnings (#3214)

This commit resolves all outstanding duplicate label
and duplicate citation warnings.
I have not yet addressed unreferenced footnote warnings.

I took the general strategy of replacing a target above a section heading
with references directly to that section heading,
or where impractical, disambiguting the target with ``PEP NNN``.
I also converted all the citations in PEP 482 to links,
as they were causing duplicate citation warnings.

Author: AA-Turner

pep-0394.txt

@@ -183,8 +183,6 @@ administrators with the freedom to configure their systems based on
 the needs of their particular environment.
 
 
-.. _rationale:
-
 Current Rationale
 =================
 

pep-0400.txt

@@ -84,7 +84,7 @@ StreamReader and StreamWriter issues
   supports UNIX newlines ('\\n').
 * StreamReader and StreamWriter are stateful codecs but don't expose
   functions to control their state (getstate() or setstate()). Each
-  codec has to handle corner cases, see `Appendix A`_.
+  codec has to handle corner cases, see `Appendix A <PEP 400 Appendix A_>`_.
 * StreamReader and StreamWriter are very similar to IncrementalReader
   and IncrementalEncoder, some code is duplicated for stateful codecs
   (e.g. UTF-16).
@@ -207,7 +207,7 @@ Python 3.3. Defining a subclass doesn't emit a DeprecationWarning.
 codecs.open() will be changed to reuse the builtin open() function
 (TextIOWrapper) to read-write text files.
 
-.. _Appendix A:
+.. _PEP 400 Appendix A:
 
 Alternative Approach
 ====================

pep-0482.txt

@@ -26,48 +26,61 @@ Existing Approaches for Python
 mypy
 ----
 
-(This section is a stub, since mypy [mypy]_ is essentially what we're
+(This section is a stub, since `mypy`__ is essentially what we're
 proposing.)
 
+__ https://mypy-lang.org
+
 
 Reticulated Python
 ------------------
 
-Reticulated Python [reticulated]_ by Michael Vitousek is an example of
+`Reticulated Python`__ by Michael Vitousek is an example of
 a slightly different approach to gradual typing for Python. It is
-described in an actual academic paper [reticulated-paper]_ written by
+described in an actual `academic paper`__ written by
 Vitousek with Jeremy Siek and Jim Baker (the latter of Jython fame).
 
+__ https://github.com/mvitousek/reticulated
+__ http://wphomes.soic.indiana.edu/jsiek/files/2014/03/retic-python.pdf
 
 PyCharm
 -------
 
 PyCharm by JetBrains has been providing a way to specify and check
-types for about four years.  The type system suggested by PyCharm
-[pycharm]_ grew from simple class types to tuple types, generic types,
+types for about four years.  The type system suggested by PyCharm__
+grew from simple class types to tuple types, generic types,
 function types, etc. based on feedback of many users who shared their
 experience of using type hints in their code.
 
+__ https://github.com/JetBrains/python-skeletons#types
 
 Others
 ------
 
-TBD: Add sections on pyflakes [pyflakes]_, pylint [pylint]_, numpy
-[numpy]_, Argument Clinic [argumentclinic]_, pytypedecl [pytypedecl]_,
-numba [numba]_, obiwan [obiwan]_.
+TBD: Add sections on pyflakes__, pylint__, numpy__,
+`Argument Clinic`__, pytypedecl__, numba__, obiwan__.
 
+__ https://github.com/pyflakes/pyflakes/
+__ https://www.pylint.org
+__ https://www.numpy.org
+__ https://docs.python.org/3/howto/clinic.html
+__ https://github.com/google/pytypedecl
+__ https://numba.pydata.org
+__ https://pypi.org/project/obiwan
 
 Existing Approaches in Other Languages
 ======================================
 
 ActionScript
 ------------
 
-ActionScript [actionscript]_ is a class-based, single inheritance,
+ActionScript__ is a class-based, single inheritance,
 object-oriented superset of ECMAScript.  It supports inferfaces and
 strong runtime-checked static typing.  Compilation supports a “strict
 dialect” where type mismatches are reported at compile-time.
 
+__ https://livedocs.adobe.com/specs/actionscript/3/
+
 Example code with types::
 
   package {
@@ -95,10 +108,12 @@ Example code with types::
 Dart
 ----
 
-Dart [dart]_ is a class-based, single inheritance, object-oriented
+Dart__ is a class-based, single inheritance, object-oriented
 language with C-style syntax.  It supports interfaces, abstract classes,
 reified generics, and optional typing.
 
+__ https://www.dartlang.org
+
 Types are inferred when possible.  The runtime differentiates between two
 modes of execution: *checked mode* aimed for development (catching type
 errors at runtime) and *production mode* recommended for speed execution
@@ -121,10 +136,12 @@ Example code with types::
 Hack
 ----
 
-Hack [hack]_ is a programming language that interoperates seamlessly
+Hack__ is a programming language that interoperates seamlessly
 with PHP.  It provides opt-in static type checking, type aliasing,
 generics, nullable types, and lambdas.
 
+__ https://hacklang.org
+
 Example code with types::
 
   <?hh
@@ -148,9 +165,11 @@ Example code with types::
 TypeScript
 ----------
 
-TypeScript [typescript]_ is a typed superset of JavaScript that adds
+TypeScript__ is a typed superset of JavaScript that adds
 interfaces, classes, mixins and modules to the language.
 
+__ http://www.typescriptlang.org
+
 Type checks are duck typed.  Multiple valid function signatures are
 specified by supplying overloaded function declarations.  Functions and
 classes can use generics as type parameterization.  Interfaces can have
@@ -195,67 +214,7 @@ Example code with types::
   }
 
 
-References
-==========
-
-.. [mypy]
-   http://mypy-lang.org
-
-.. [reticulated]
-   https://github.com/mvitousek/reticulated
-
-.. [reticulated-paper]
-   http://wphomes.soic.indiana.edu/jsiek/files/2014/03/retic-python.pdf
-
-.. [pycharm]
-   https://github.com/JetBrains/python-skeletons#types
-
-.. [obiwan]
-   http://pypi.python.org/pypi/obiwan
-
-.. [numba]
-   http://numba.pydata.org
-
-.. [pytypedecl]
-   https://github.com/google/pytypedecl
-
-.. [argumentclinic]
-   https://docs.python.org/3/howto/clinic.html
-
-.. [numpy]
-   http://www.numpy.org
-
-.. [typescript]
-   http://www.typescriptlang.org
-
-.. [hack]
-   http://hacklang.org
-
-.. [dart]
-   https://www.dartlang.org
-
-.. [actionscript]
-   http://livedocs.adobe.com/specs/actionscript/3/
-
-.. [pyflakes]
-   https://github.com/pyflakes/pyflakes/
-
-.. [pylint]
-   http://www.pylint.org
-
-
 Copyright
 =========
 
 This document has been placed in the public domain.
-
-
-
-..
-   Local Variables:
-   mode: indented-text
-   indent-tabs-mode: nil
-   sentence-end-double-space: t
-   fill-column: 70
-   coding: utf-8
-   End:

pep-0526.txt

@@ -31,7 +31,7 @@ There was preliminary discussion on python-ideas and at
 https://github.com/python/typing/issues/258.
 
 Before you bring up an objection in a public forum please at least
-read the summary of `rejected`_ ideas listed at the end of this PEP.
+read the summary of `rejected ideas <PEP 526 rejected_>`_ listed at the end of this PEP.
 
 
 Abstract
@@ -395,8 +395,8 @@ Changes to Standard Library and Documentation
   instances. This restriction is ensured by static checkers,
   but not at runtime. See the
   `classvar`_ section for examples and explanations for the usage of
-  ``ClassVar``, and see the `rejected`_ section for more information on
-  the reasoning behind ``ClassVar``.
+  ``ClassVar``, and see the `rejected <PEP 526 rejected_>`_ section
+  for more information on the reasoning behind ``ClassVar``.
 
 - Function ``get_type_hints`` in the ``typing`` module will be extended,
   so that one can retrieve type annotations at runtime from modules
@@ -511,7 +511,7 @@ These stored annotations might be used for other purposes,
 but with this PEP we explicitly recommend type hinting as the
 preferred use of annotations.
 
-.. _rejected:
+.. _PEP 526 rejected:
 
 Rejected/Postponed Proposals
 ============================

pep-0544.txt

@@ -24,7 +24,7 @@ static and runtime semantics of protocol classes that will provide a support
 for *structural* subtyping (static duck typing).
 
 
-.. _rationale:
+.. _PEP 544 rationale:
 
 Rationale and Goals
 ===================
@@ -86,8 +86,8 @@ subtyping have their strengths and weaknesses. Therefore, in this PEP we
 *do not propose* to replace the nominal subtyping described by :pep:`484` with
 structural subtyping completely. Instead, protocol classes as specified in
 this PEP complement normal classes, and users are free to choose
-where to apply a particular solution. See section on `rejected`_ ideas at the
-end of this PEP for additional motivation.
+where to apply a particular solution. See section on `rejected
+<PEP 544 rejected_>`_ ideas at the end of this PEP for additional motivation.
 
 
 Non-goals
@@ -181,8 +181,9 @@ approaches related to structural subtyping in Python and other languages:
     assert issubclass(tuple, MyTuple)
     assert isinstance((), MyTuple)
 
-  As mentioned in the `rationale`_, we want to avoid such necessity, especially
-  in static context. However, in a runtime context, ABCs are good candidates for
+  As mentioned in the `rationale <PEP 544 rationale_>`_,
+  we want to avoid such necessity, especially in static context.
+  However, in a runtime context, ABCs are good candidates for
   protocol classes and they are already used extensively in
   the ``typing`` module.
 
@@ -200,8 +201,9 @@ approaches related to structural subtyping in Python and other languages:
     assert isinstance(MyIterable(), Iterable)
 
   Such behavior seems to be a perfect fit for both runtime and static behavior
-  of protocols. As discussed in `rationale`_, we propose to add static support
-  for such behavior. In addition, to allow users to achieve such runtime
+  of protocols. As discussed in `rationale <PEP 544 rationale_>`_,
+  we propose to add static support for such behavior.
+  In addition, to allow users to achieve such runtime
   behavior for *user-defined* protocols a special ``@runtime_checkable`` decorator
   will be provided, see detailed `discussion`_ below.
 
@@ -225,9 +227,9 @@ approaches related to structural subtyping in Python and other languages:
   prohibits redundant members in implementations. While the idea of
   optional members looks interesting, it would complicate this proposal and
   it is not clear how useful it will be. Therefore, it is proposed to postpone
-  this; see `rejected`_ ideas. In general, the idea of static protocol
-  checking without runtime implications looks reasonable, and basically
-  this proposal follows the same line.
+  this; see `rejected <PEP 544 rejected_>`_ ideas. In general, the idea of
+  static protocol checking without runtime implications looks reasonable,
+  and basically this proposal follows the same line.
 
 * Go [golang]_ uses a more radical approach and makes interfaces the primary
   way to provide type information. Also, assignments are used to explicitly
@@ -242,11 +244,9 @@ approaches related to structural subtyping in Python and other languages:
     }
 
   Both these ideas are questionable in the context of this proposal. See
-  the section on `rejected`_ ideas.
+  the section on `rejected <PEP 544 rejected_>`_ ideas.
 
 
-.. _specification:
-
 Specification
 =============
 
@@ -496,8 +496,9 @@ considering subtyping, since structural compatibility is
 the criterion, not the MRO.
 
 If ``Protocol`` is included in the base class list, all the other base classes
-must be protocols. A protocol can't extend a regular class, see `rejected`_
-ideas for rationale. Note that rules around explicit subclassing are different
+must be protocols. A protocol can't extend a regular class, see `rejected
+<PEP 544 rejected_>`_ ideas for rationale.
+Note that rules around explicit subclassing are different
 from regular ABCs, where abstractness is simply defined by having at least one
 abstract method being unimplemented. Protocol classes must be marked
 *explicitly*.
@@ -551,7 +552,7 @@ the declared variance. Examples::
 
 Note that unlike nominal classes, de facto covariant protocols cannot be
 declared as invariant, since this can break transitivity of subtyping
-(see `rejected`_ ideas for details). For example::
+(see `rejected <PEP 544 rejected_>`_ ideas for details). For example::
 
   T = TypeVar('T')
 
@@ -732,7 +733,7 @@ Example::
 
 If this will prove to be a widely used scenario, then a special
 intersection type construct could be added in future as specified by :pep:`483`,
-see `rejected`_ ideas for more details.
+see `rejected <PEP 544 rejected_>`_ ideas for more details.
 
 
 ``Type[]`` and class objects vs protocols
@@ -888,7 +889,8 @@ that provides the same semantics for class and instance checks as for
   assert isinstance(open('some/file'), SupportsClose)
 
 Note that instance checks are not 100% reliable statically, this is why
-this behavior is opt-in, see section on `rejected`_ ideas for examples.
+this behavior is opt-in, see section on `rejected <PEP 544 rejected_>`_
+ideas for examples.
 The most type checkers can do is to treat ``isinstance(obj, Iterator)``
 roughly as a simpler way to write
 ``hasattr(x, '__iter__') and hasattr(x, '__next__')``. To minimize
@@ -1027,7 +1029,7 @@ at runtime in this case). But together with other introspection tools this
 give a reasonable perspective for runtime type checking tools.
 
 
-.. _rejected:
+.. _PEP 544 rejected:
 
 Rejected/Postponed Ideas
 ========================
@@ -1498,14 +1500,3 @@ Copyright
 =========
 
 This document has been placed in the public domain.
-
-
-
-..
-   Local Variables:
-   mode: indented-text
-   indent-tabs-mode: nil
-   sentence-end-double-space: t
-   fill-column: 70
-   coding: utf-8
-   End: