DOC: Change NEP hardlinks to intersphinx mappings.

This pull request changes most explicit URL links to NEPs from NEPs to be intersphinx mappings. I believe this will complete my work on changes to address numpy#26707 except as needed to address review comments.

[skip actions] [skip azp] [skip cirrus]

Author: eagunn

doc/neps/content.rst

@@ -16,10 +16,7 @@ Roadmap
    Index <index>
    The Scope of NumPy <scope>
    Current roadmap <roadmap>
-   Wishlist (opens new window) |wishlist_link|
+   Wish list <https://github.com/numpy/numpy/issues?q=is%3Aopen+is%3Aissue+label%3A%2223+-+Wish+List%22>
 
-.. |wishlist_link| raw:: html
-
-   <a href="https://github.com/numpy/numpy/issues?q=is%3Aopen+is%3Aissue+label%3A%2223+-+Wish+List%22" target=" blank">WishList</a>
 
 

doc/neps/nep-0018-array-function-protocol.rst

@@ -141,7 +141,7 @@ The type of ``types`` is intentionally vague:
 instead for performance reasons. In any case, ``__array_function__``
 implementations should not rely on the iteration order of ``types``, which
 would violate a well-defined "Type casting hierarchy" (as described in
-`NEP-13 <https://www.numpy.org/neps/nep-0013-ufunc-overrides.html>`_).
+:ref:`NEP-13 <NEP13>`).
 
 Example for a project implementing the NumPy API
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -300,7 +300,7 @@ are valid then which has precedence?
 
 For the most part, the rules for dispatch with ``__array_function__``
 match those for ``__array_ufunc__`` (see
-`NEP-13 <https://www.numpy.org/neps/nep-0013-ufunc-overrides.html>`_).
+:ref:`NEP-13 <NEP13>`).
 In particular:
 
 -  NumPy will gather implementations of ``__array_function__`` from all
@@ -819,7 +819,7 @@ don't think it makes sense to do so now, because code generation involves
 tradeoffs and NumPy's experience with type annotations is still
 `quite limited <https://github.com/numpy/numpy-stubs>`_. Even if NumPy
 was Python 3 only (which will happen
-`sometime in 2019 <http://www.numpy.org/neps/nep-0014-dropping-python2.7-proposal.html>`_),
+:ref:`sometime in 2019 <NEP14>`),
 we aren't ready to annotate NumPy's codebase directly yet.
 
 Support for implementation-specific arguments

doc/neps/nep-0030-duck-array-protocol.rst

@@ -176,7 +176,7 @@ Previous proposals and discussion
 ---------------------------------
 
 The duck typing protocol proposed here was described in a high level in
-`NEP 22 <https://numpy.org/neps/nep-0022-ndarray-duck-typing-overview.html>`_.
+:ref:`NEP 22 <NEP22>`.
 
 Additionally, longer discussions about the protocol and related proposals
 took place in

doc/neps/nep-0031-uarray.rst

@@ -319,7 +319,7 @@ It has been formally realized (at least in part) that a backend system is
 needed for this, in the `NumPy roadmap <https://numpy.org/neps/roadmap.html#other-functionality>`_.
 
 For ``numpy.random``, it's still necessary to make the C-API fit the one
-proposed in `NEP-19 <https://numpy.org/neps/nep-0019-rng-policy.html>`_.
+proposed in :ref:`NEP-19 <NEP19>`.
 This is impossible for `mkl-random`, because then it would need to be
 rewritten to fit that framework. The guarantees on stream
 compatibility will be the same as before, but if there's a backend that affects
@@ -620,8 +620,8 @@ Discussion
 ----------
 
 * ``uarray`` blogpost: https://labs.quansight.org/blog/2019/07/uarray-update-api-changes-overhead-and-comparison-to-__array_function__/
-* The discussion section of NEP-18: https://numpy.org/neps/nep-0018-array-function-protocol.html#discussion
-* NEP-22: https://numpy.org/neps/nep-0022-ndarray-duck-typing-overview.html
+* The discussion section of :ref:`NEP18`
+* :ref:`NEP22`
 * Dask issue #4462: https://github.com/dask/dask/issues/4462
 * PR #13046: https://github.com/numpy/numpy/pull/13046
 * Dask issue #4883: https://github.com/dask/dask/issues/4883
@@ -636,11 +636,11 @@ References and footnotes
 
 .. [1] uarray, A general dispatch mechanism for Python: https://uarray.readthedocs.io
 
-.. [2] NEP 18 — A dispatch mechanism for NumPy’s high level array functions: https://numpy.org/neps/nep-0018-array-function-protocol.html
+.. [2] :ref:`NEP18`
 
-.. [3] NEP 22 — Duck typing for NumPy arrays – high level overview: https://numpy.org/neps/nep-0022-ndarray-duck-typing-overview.html
+.. [3] :ref:`NEP22`
 
-.. [4] NEP 13 — A Mechanism for Overriding Ufuncs: https://numpy.org/neps/nep-0013-ufunc-overrides.html
+.. [4] :ref:`NEP13`
 
 .. [5] Reply to Adding to the non-dispatched implementation of NumPy methods: https://mail.python.org/archives/list/[email protected]/thread/5GUDMALWDIRHITG5YUOCV343J66QSX3U/#5GUDMALWDIRHITG5YUOCV343J66QSX3U
 
@@ -650,7 +650,7 @@ References and footnotes
 
 .. [8] unumpy: NumPy, but implementation-independent: https://unumpy.readthedocs.io
 
-.. [9] NEP 30 — Duck Typing for NumPy Arrays - Implementation: https://www.numpy.org/neps/nep-0030-duck-array-protocol.html
+.. [9] :ref:`NEP30`
 
 .. [10] http://scipy.github.io/devdocs/fft.html#backend-control
 

doc/neps/nep-0035-array-creation-dispatch-with-array-function.rst

@@ -430,17 +430,17 @@ Discussion
 References
 ----------
 
-.. [1] `NEP 18 - A dispatch mechanism for NumPy's high level array functions <https://numpy.org/neps/nep-0018-array-function-protocol.html>`_.
+.. [1] :ref:`NEP18`.
 
 .. [2] `PEP 3102 — Keyword-Only Arguments <https://www.python.org/dev/peps/pep-3102/>`_.
 
-.. [3] `NEP 30 — Duck Typing for NumPy Arrays - Implementation <https://numpy.org/neps/nep-0030-duck-array-protocol.html>`_.
+.. [3] :ref:`NEP30`.
 
-.. [4] `NEP 31 — Context-local and global overrides of the NumPy API <https://github.com/numpy/numpy/pull/14389>`_.
+.. [4] :ref:`NEP31`.
 
 .. [5] `Array creation routines <https://docs.scipy.org/doc/numpy-1.17.0/reference/routines.array-creation.html>`_.
 
-.. [6] `NEP 37 — A dispatch protocol for NumPy-like modules <https://numpy.org/neps/nep-0037-array-module.html>`_.
+.. [6] :ref:`NEP37`.
 
 .. [7] `Implementation's pull request on GitHub <https://github.com/numpy/numpy/pull/16935>`_
 

doc/neps/nep-0036-fair-play.rst

@@ -121,10 +121,8 @@ Fair play rules
 
 4. *DO* use official mechanism to engage with the API.
 
-   Protocols such as `__array_ufunc__
-   <https://numpy.org/neps/nep-0013-ufunc-overrides.html>`__ and
-   `__array_function__
-   <https://numpy.org/neps/nep-0018-array-function-protocol.html>`__
+   Protocols such as :ref:`__array_ufunc__ <NEP13>` and
+   :ref:`__array_function__ <NEP18>`
    were designed to help external packages interact more easily with
    NumPy.  E.g., the latter allows objects from foreign libraries to
    pass through NumPy.  We actively encourage using any of

doc/neps/nep-0037-array-module.rst

@@ -29,7 +29,7 @@ expect will make it easier to adopt.
 Why ``__array_function__`` hasn't been enough
 ---------------------------------------------
 
-There are two broad ways in which NEP-18 has fallen short of its goals:
+There are two broad ways in which :ref:`NEP-18 <NEP18>` has fallen short of its goals:
 
 1. **Backwards compatibility concerns**. `__array_function__` has significant
    implications for libraries that use it:
@@ -64,16 +64,15 @@ There are two broad ways in which NEP-18 has fallen short of its goals:
 
    - **Array creation** routines (e.g., ``np.arange`` and those in
      ``np.random``) need some other mechanism for indicating what type of
-     arrays to create. `NEP 35 <https://numpy.org/neps/nep-0035-array-creation-dispatch-with-array-function.html>`_
+     arrays to create. :ref:`NEP 35 <NEP35>`
      proposed adding optional ``like=`` arguments to functions without
      existing array arguments. However, we still lack any mechanism to
      override methods on objects, such as those needed by
      ``np.random.RandomState``.
    - **Array conversion** can't reuse the existing coercion functions like
      ``np.asarray``, because ``np.asarray`` sometimes means "convert to an
      exact ``np.ndarray``" and other times means "convert to something _like_
-     a NumPy array." This led to the `NEP 30
-     <https://numpy.org/neps/nep-0030-duck-array-protocol.html>`_ proposal for
+     a NumPy array." This led to the :ref:`NEP 30 <NEP30>` proposal for
      a separate ``np.duckarray`` function, but this still does not resolve how
      to cast one duck array into a type matching another duck array.
 
@@ -144,8 +143,8 @@ we can simply pull out the appropriate submodule:
         noise = module.random.randn(*array.shape)
         return array + noise
 
-We can also write the duck-array ``stack`` function from `NEP 30
-<https://numpy.org/neps/nep-0030-duck-array-protocol.html>`_, without the need
+We can also write the duck-array ``stack`` function from 
+:ref:`NEP 30 <NEP30>`, without the need
 for a new ``np.duckarray`` function:
 
 .. code:: python

doc/neps/nep-0054-simd-cpp-highway.rst

@@ -17,7 +17,7 @@ Abstract
 We are moving the SIMD intrinsic framework, Universal Intrinsics, from C to
 C++. We have also moved to Meson as the build system. The Google Highway
 intrinsics project is proposing we use Highway instead of our Universal
-Intrinsics as described in `NEP 38`_. This is a complex and multi-faceted
+Intrinsics as described in :ref:`NEP 38 <NEP38>`. This is a complex and multi-faceted
 decision - this NEP is an attempt to describe the trade-offs involved and
 what would need to be done.
 
@@ -350,7 +350,6 @@ References and Footnotes
    this NEP as an example) or licensed under the `Open Publication License`_.
 
 .. _Open Publication License: https://www.opencontent.org/openpub/
-.. _`NEP 38`: https://numpy.org/neps/nep-0038-SIMD-optimizations.html
 .. _`gh-20866`: https://github.com/numpy/numpy/pull/20866
 .. _`gh-21057`: https://github.com/numpy/numpy/pull/21057
 .. _`gh-23096`: https://github.com/numpy/numpy/pull/23096