Use automatic PEP links in doc

docs/src/reference/special_methods_table.rst

@@ -201,7 +201,7 @@ Descriptor objects
 .. note::
     Descriptor objects are part of the support mechanism for new-style
     Python classes. See the discussion of descriptors in the Python documentation.
-    See also PEP 252, "Making Types Look More Like Classes", and PEP 253,
+    See also :PEP:`252`, "Making Types Look More Like Classes", and :PEP:`253`,
     "Subtyping Built-In Types".
 
 +-----------------------+---------------------------------------+-------------+-----------------------------------------------------+

docs/src/tutorial/strings.rst

@@ -67,7 +67,7 @@ Cython understands all Python string type prefixes:
 * ``b'bytes'`` for byte strings
 * ``u'text'`` for Unicode strings
 * ``f'formatted {value}'`` for formatted Unicode string literals as defined by
-  `PEP 498 <https://www.python.org/dev/peps/pep-0498/>`_ (added in Cython 0.24)
+  :PEP:`498` (added in Cython 0.24)
 
 Unprefixed string literals become :obj:`str` objects when compiling
 with language level 2 and :obj:`unicode` objects (i.e. Python 3
@@ -558,7 +558,7 @@ When string literals appear in the code, the source code encoding is
 important.  It determines the byte sequence that Cython will store in
 the C code for bytes literals, and the Unicode code points that Cython
 builds for unicode literals when parsing the byte encoded source file.
-Following `PEP 263`_, Cython supports the explicit declaration of
+Following :PEP:`263`, Cython supports the explicit declaration of
 source file encodings.  For example, putting the following comment at
 the top of an ``ISO-8859-15`` (Latin-9) encoded source file (into the
 first or second line) is required to enable ``ISO-8859-15`` decoding
@@ -567,14 +567,12 @@ in the parser::
     # -*- coding: ISO-8859-15 -*-
 
 When no explicit encoding declaration is provided, the source code is
-parsed as UTF-8 encoded text, as specified by `PEP 3120`_.  `UTF-8`_
+parsed as UTF-8 encoded text, as specified by :PEP:`3120`.  `UTF-8`_
 is a very common encoding that can represent the entire Unicode set of
 characters and is compatible with plain ASCII encoded text that it
 encodes efficiently.  This makes it a very good choice for source code
 files which usually consist mostly of ASCII characters.
 
-.. _`PEP 263`: http://www.python.org/dev/peps/pep-0263/
-.. _`PEP 3120`: http://www.python.org/dev/peps/pep-3120/
 .. _`UTF-8`: http://en.wikipedia.org/wiki/UTF-8
 
 As an example, putting the following line into a UTF-8 encoded source
@@ -731,15 +729,14 @@ to the internal representation of the Unicode string.  Instead, any
 Unicode character can be represented on all platforms without
 resorting to surrogate pairs.  This implies that narrow builds no
 longer exist from that version on, regardless of the size of
-:c:type:`Py_UNICODE`.  See
-`PEP 393 <http://www.python.org/dev/peps/pep-0393/>`_  for details.
+:c:type:`Py_UNICODE`.  See :PEP:`393` for details.
 
 Cython 0.16 and later handles this change internally and does the right
 thing also for single character values as long as either type inference
 is applied to untyped variables or the portable :c:type:`Py_UCS4` type
 is explicitly used in the source code instead of the platform specific
 :c:type:`Py_UNICODE` type.  Optimisations that Cython applies to the
-Python unicode type will automatically adapt to PEP 393 at C compile
+Python unicode type will automatically adapt to :PEP:`393` at C compile
 time, as usual.
 
 Iteration

docs/src/userguide/buffer.rst

@@ -176,8 +176,7 @@ References
 ----------
 
 The buffer interface used here is set out in
-`PEP 3118, Revising the buffer protocol
-<http://legacy.python.org/dev/peps/pep-3118/>`_
+:PEP:`3118`, Revising the buffer protocol.
 
 A tutorial for using this API from C is on Jake Vanderplas's blog,
 `An Introduction to the Python Buffer Protocol
@@ -188,5 +187,5 @@ Reference documentation is available for
 and `Python 2 <https://docs.python.org/2.7/c-api/buffer.html>`_.
 The Py2 documentation also describes an older buffer protocol
 that is no longer in use;
-since Python 2.6, the PEP 3118 protocol has been implemented,
+since Python 2.6, the :PEP:`3118` protocol has been implemented,
 and the older protocol is only relevant for legacy code.

docs/src/userguide/pyrex_differences.rst

@@ -310,9 +310,7 @@ Synonyms
 Source code encoding
 ======================
 
-.. TODO: add the links to the relevant PEPs
-
-Cython supports PEP 3120 and PEP 263, i.e. you can start your Cython source
+Cython supports :PEP:`3120` and :PEP:`263`, i.e. you can start your Cython source
 file with an encoding comment and generally write your source code in UTF-8.
 This impacts the encoding of byte strings and the conversion of unicode string
 literals like ``u'abcd'`` to unicode objects.

docs/src/userguide/special_methods.rst

@@ -329,8 +329,8 @@ Iterators
 | __next__ 	        | self 	                                | object      |	Get next item (called next in Python)               |
 +-----------------------+---------------------------------------+-------------+-----------------------------------------------------+
 
-Buffer interface [PEP 3118] (no Python equivalents - see note 1)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Buffer interface [:PEP:`3118`] (no Python equivalents - see note 1)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 +-----------------------+---------------------------------------+-------------+-----------------------------------------------------+
 | Name                  | Parameters                            | Return type |         Description                                 |
@@ -371,11 +371,10 @@ Descriptor objects (see note 2)
 .. note:: (1) The buffer interface was intended for use by C code and is not directly
         accessible from Python. It is described in the Python/C API Reference Manual
         of Python 2.x under sections 6.6 and 10.6. It was superseded by the new
-        PEP 3118 buffer protocol in Python 2.6 and is no longer available in Python 3.
+        :PEP:`3118` buffer protocol in Python 2.6 and is no longer available in Python 3.
         For a how-to guide to the new API, see :ref:`buffer`.
 
 .. note:: (2) Descriptor objects are part of the support mechanism for new-style
         Python classes. See the discussion of descriptors in the Python documentation.
-        See also PEP 252, "Making Types Look More Like Classes", and PEP 253,
+        See also :PEP:`252`, "Making Types Look More Like Classes", and :PEP:`253`,
         "Subtyping Built-In Types".
-