Migrate to Sphinx 1.0 C language constructs.

9 files changed, 213 insertions, 213 deletions

diff --git a/Doc/whatsnew/2.2.rst b/Doc/whatsnew/2.2.rst
index 89e4d76..412c1d0 100644
--- a/Doc/whatsnew/2.2.rst
+++ b/Doc/whatsnew/2.2.rst
@@ -754,7 +754,7 @@ Here are the changes 2.2 introduces:
 
 * Classes can define methods called :meth:`__truediv__` and :meth:`__floordiv__`
   to overload the two division operators.  At the C level, there are also slots in
-  the :ctype:`PyNumberMethods` structure so extension types can define the two
+  the :c:type:`PyNumberMethods` structure so extension types can define the two
   operators.
 
 * Python 2.2 supports some command-line arguments for testing whether code will
@@ -983,7 +983,7 @@ New and Improved Modules
   Jun-ichiro "itojun" Hagino.)
 
 * Two new format characters were added to the :mod:`struct` module for 64-bit
-  integers on platforms that support the C :ctype:`long long` type.  ``q`` is for
+  integers on platforms that support the C :c:type:`long long` type.  ``q`` is for
   a signed 64-bit integer, and ``Q`` is for an unsigned one.  The value is
   returned in Python's long integer type.  (Contributed by Tim Peters.)
 
@@ -1057,16 +1057,16 @@ code, none of the changes described here will affect you very much.
   at much higher speeds than Python-based functions and should reduce the overhead
   of profiling and tracing.  This  will be of interest to authors of development
   environments for Python.  Two new C functions were added to Python's API,
-  :cfunc:`PyEval_SetProfile` and :cfunc:`PyEval_SetTrace`. The existing
+  :c:func:`PyEval_SetProfile` and :c:func:`PyEval_SetTrace`. The existing
   :func:`sys.setprofile` and :func:`sys.settrace` functions still exist, and have
   simply been changed to use the new C-level interface.  (Contributed by Fred L.
   Drake, Jr.)
 
 * Another low-level API, primarily of interest to implementors of Python
-  debuggers and development tools, was added. :cfunc:`PyInterpreterState_Head` and
-  :cfunc:`PyInterpreterState_Next` let a caller walk through all the existing
-  interpreter objects; :cfunc:`PyInterpreterState_ThreadHead` and
-  :cfunc:`PyThreadState_Next` allow looping over all the thread states for a given
+  debuggers and development tools, was added. :c:func:`PyInterpreterState_Head` and
+  :c:func:`PyInterpreterState_Next` let a caller walk through all the existing
+  interpreter objects; :c:func:`PyInterpreterState_ThreadHead` and
+  :c:func:`PyThreadState_Next` allow looping over all the thread states for a given
   interpreter.  (Contributed by David Beazley.)
 
 * The C-level interface to the garbage collector has been changed to make it
@@ -1078,19 +1078,19 @@ code, none of the changes described here will affect you very much.
 
   To upgrade an extension module to the new API, perform the following steps:
 
-* Rename :cfunc:`Py_TPFLAGS_GC` to :cfunc:`PyTPFLAGS_HAVE_GC`.
+* Rename :c:func:`Py_TPFLAGS_GC` to :c:func:`PyTPFLAGS_HAVE_GC`.
 
-* Use :cfunc:`PyObject_GC_New` or :cfunc:`PyObject_GC_NewVar` to allocate
-    objects, and :cfunc:`PyObject_GC_Del` to deallocate them.
+* Use :c:func:`PyObject_GC_New` or :c:func:`PyObject_GC_NewVar` to allocate
+    objects, and :c:func:`PyObject_GC_Del` to deallocate them.
 
-* Rename :cfunc:`PyObject_GC_Init` to :cfunc:`PyObject_GC_Track` and
-    :cfunc:`PyObject_GC_Fini` to :cfunc:`PyObject_GC_UnTrack`.
+* Rename :c:func:`PyObject_GC_Init` to :c:func:`PyObject_GC_Track` and
+    :c:func:`PyObject_GC_Fini` to :c:func:`PyObject_GC_UnTrack`.
 
-* Remove :cfunc:`PyGC_HEAD_SIZE` from object size calculations.
+* Remove :c:func:`PyGC_HEAD_SIZE` from object size calculations.
 
-* Remove calls to :cfunc:`PyObject_AS_GC` and :cfunc:`PyObject_FROM_GC`.
+* Remove calls to :c:func:`PyObject_AS_GC` and :c:func:`PyObject_FROM_GC`.
 
-* A new ``et`` format sequence was added to :cfunc:`PyArg_ParseTuple`; ``et``
+* A new ``et`` format sequence was added to :c:func:`PyArg_ParseTuple`; ``et``
   takes both a parameter and an encoding name, and converts the parameter to the
   given encoding if the parameter turns out to be a Unicode string, or leaves it
   alone if it's an 8-bit string, assuming it to already be in the desired
@@ -1099,10 +1099,10 @@ code, none of the changes described here will affect you very much.
   specified new encoding. (Contributed by M.-A. Lemburg, and used for the MBCS
   support on Windows described in the following section.)
 
-* A different argument parsing function, :cfunc:`PyArg_UnpackTuple`, has been
+* A different argument parsing function, :c:func:`PyArg_UnpackTuple`, has been
   added that's simpler and presumably faster.  Instead of specifying a format
   string, the caller simply gives the minimum and maximum number of arguments
-  expected, and a set of pointers to :ctype:`PyObject\*` variables that will be
+  expected, and a set of pointers to :c:type:`PyObject\*` variables that will be
   filled in with argument values.
 
 * Two new flags :const:`METH_NOARGS` and :const:`METH_O` are available in method
@@ -1111,14 +1111,14 @@ code, none of the changes described here will affect you very much.
   corresponding method that uses :const:`METH_VARARGS`.  Also, the old
   :const:`METH_OLDARGS` style of writing C methods is  now officially deprecated.
 
-* Two new wrapper functions, :cfunc:`PyOS_snprintf` and :cfunc:`PyOS_vsnprintf`
+* Two new wrapper functions, :c:func:`PyOS_snprintf` and :c:func:`PyOS_vsnprintf`
   were added to provide  cross-platform implementations for the relatively new
-  :cfunc:`snprintf` and :cfunc:`vsnprintf` C lib APIs. In contrast to the standard
-  :cfunc:`sprintf` and :cfunc:`vsprintf` functions, the Python versions check the
+  :c:func:`snprintf` and :c:func:`vsnprintf` C lib APIs. In contrast to the standard
+  :c:func:`sprintf` and :c:func:`vsprintf` functions, the Python versions check the
   bounds of the buffer used to protect against buffer overruns. (Contributed by
   M.-A. Lemburg.)
 
-* The :cfunc:`_PyTuple_Resize` function has lost an unused parameter, so now it
+* The :c:func:`_PyTuple_Resize` function has lost an unused parameter, so now it
   takes 2 parameters instead of 3.  The third argument was never used, and can
   simply be discarded when porting code from earlier versions to Python 2.2.
 
@@ -1219,7 +1219,7 @@ Some of the more notable changes are:
   operator, but these features were rarely used and therefore buggy.  The
   :meth:`tolist` method and the :attr:`start`, :attr:`stop`, and :attr:`step`
   attributes are also being deprecated.  At the C level, the fourth argument to
-  the :cfunc:`PyRange_New` function, ``repeat``, has also been deprecated.
+  the :c:func:`PyRange_New` function, ``repeat``, has also been deprecated.
 
 * There were a bunch of patches to the dictionary implementation, mostly to fix
   potential core dumps if a dictionary contains objects that sneakily changed
@@ -1242,8 +1242,8 @@ Some of the more notable changes are:
   up to display the output.  This patch makes it possible to import such scripts,
   in case they're also usable as modules.  (Implemented by David Bolen.)
 
-* On platforms where Python uses the C :cfunc:`dlopen` function  to load
-  extension modules, it's now possible to set the flags used  by :cfunc:`dlopen`
+* On platforms where Python uses the C :c:func:`dlopen` function  to load
+  extension modules, it's now possible to set the flags used  by :c:func:`dlopen`
   using the :func:`sys.getdlopenflags` and :func:`sys.setdlopenflags` functions.
   (Contributed by Bram Stolk.)
 
diff --git a/Doc/whatsnew/2.3.rst b/Doc/whatsnew/2.3.rst
index 3894f87..0cc29f6 100644
--- a/Doc/whatsnew/2.3.rst
+++ b/Doc/whatsnew/2.3.rst
@@ -1797,8 +1797,8 @@ Pymalloc: A Specialized Object Allocator
 
 Pymalloc, a specialized object allocator written by Vladimir Marangozov, was a
 feature added to Python 2.1.  Pymalloc is intended to be faster than the system
-:cfunc:`malloc` and to have less memory overhead for allocation patterns typical
-of Python programs. The allocator uses C's :cfunc:`malloc` function to get large
+:c:func:`malloc` and to have less memory overhead for allocation patterns typical
+of Python programs. The allocator uses C's :c:func:`malloc` function to get large
 pools of memory and then fulfills smaller memory requests from these pools.
 
 In 2.1 and 2.2, pymalloc was an experimental feature and wasn't enabled by
@@ -1814,13 +1814,13 @@ runtime.
 
 There's one particularly common error that causes problems.  There are a number
 of memory allocation functions in Python's C API that have previously just been
-aliases for the C library's :cfunc:`malloc` and :cfunc:`free`, meaning that if
+aliases for the C library's :c:func:`malloc` and :c:func:`free`, meaning that if
 you accidentally called mismatched functions the error wouldn't be noticeable.
 When the object allocator is enabled, these functions aren't aliases of
-:cfunc:`malloc` and :cfunc:`free` any more, and calling the wrong function to
+:c:func:`malloc` and :c:func:`free` any more, and calling the wrong function to
 free memory may get you a core dump.  For example, if memory was allocated using
-:cfunc:`PyObject_Malloc`, it has to be freed using :cfunc:`PyObject_Free`, not
-:cfunc:`free`.  A few modules included with Python fell afoul of this and had to
+:c:func:`PyObject_Malloc`, it has to be freed using :c:func:`PyObject_Free`, not
+:c:func:`free`.  A few modules included with Python fell afoul of this and had to
 be fixed; doubtless there are more third-party modules that will have the same
 problem.
 
@@ -1831,14 +1831,14 @@ one family for allocating chunks of memory and another family of functions
 specifically for allocating Python objects.
 
 * To allocate and free an undistinguished chunk of memory use the "raw memory"
-  family: :cfunc:`PyMem_Malloc`, :cfunc:`PyMem_Realloc`, and :cfunc:`PyMem_Free`.
+  family: :c:func:`PyMem_Malloc`, :c:func:`PyMem_Realloc`, and :c:func:`PyMem_Free`.
 
 * The "object memory" family is the interface to the pymalloc facility described
   above and is biased towards a large number of "small" allocations:
-  :cfunc:`PyObject_Malloc`, :cfunc:`PyObject_Realloc`, and :cfunc:`PyObject_Free`.
+  :c:func:`PyObject_Malloc`, :c:func:`PyObject_Realloc`, and :c:func:`PyObject_Free`.
 
 * To allocate and free Python objects, use the "object" family
-  :cfunc:`PyObject_New`, :cfunc:`PyObject_NewVar`, and :cfunc:`PyObject_Del`.
+  :c:func:`PyObject_New`, :c:func:`PyObject_NewVar`, and :c:func:`PyObject_Del`.
 
 Thanks to lots of work by Tim Peters, pymalloc in 2.3 also provides debugging
 features to catch memory overwrites and doubled frees in both extension modules
@@ -1877,10 +1877,10 @@ Changes to Python's build process and to the C API include:
   (:file:`libpython2.3.so`) by supplying :option:`--enable-shared` when running
   Python's :program:`configure` script.  (Contributed by Ondrej Palkovsky.)
 
-* The :cmacro:`DL_EXPORT` and :cmacro:`DL_IMPORT` macros are now deprecated.
+* The :c:macro:`DL_EXPORT` and :c:macro:`DL_IMPORT` macros are now deprecated.
   Initialization functions for Python extension modules should now be declared
-  using the new macro :cmacro:`PyMODINIT_FUNC`, while the Python core will
-  generally use the :cmacro:`PyAPI_FUNC` and :cmacro:`PyAPI_DATA` macros.
+  using the new macro :c:macro:`PyMODINIT_FUNC`, while the Python core will
+  generally use the :c:macro:`PyAPI_FUNC` and :c:macro:`PyAPI_DATA` macros.
 
 * The interpreter can be compiled without any docstrings for the built-in
   functions and modules by supplying :option:`--without-doc-strings` to the
@@ -1888,19 +1888,19 @@ Changes to Python's build process and to the C API include:
   but will also mean that you can't get help for Python's built-ins.  (Contributed
   by Gustavo Niemeyer.)
 
-* The :cfunc:`PyArg_NoArgs` macro is now deprecated, and code that uses it
+* The :c:func:`PyArg_NoArgs` macro is now deprecated, and code that uses it
   should be changed.  For Python 2.2 and later, the method definition table can
   specify the :const:`METH_NOARGS` flag, signalling that there are no arguments,
   and the argument checking can then be removed.  If compatibility with pre-2.2
   versions of Python is important, the code could use ``PyArg_ParseTuple(args,
   "")`` instead, but this will be slower than using :const:`METH_NOARGS`.
 
-* :cfunc:`PyArg_ParseTuple` accepts new format characters for various sizes of
-  unsigned integers: ``B`` for :ctype:`unsigned char`, ``H`` for :ctype:`unsigned
-  short int`,  ``I`` for :ctype:`unsigned int`,  and ``K`` for :ctype:`unsigned
+* :c:func:`PyArg_ParseTuple` accepts new format characters for various sizes of
+  unsigned integers: ``B`` for :c:type:`unsigned char`, ``H`` for :c:type:`unsigned
+  short int`,  ``I`` for :c:type:`unsigned int`,  and ``K`` for :c:type:`unsigned
   long long`.
 
-* A new function, :cfunc:`PyObject_DelItemString(mapping, char \*key)` was added
+* A new function, :c:func:`PyObject_DelItemString(mapping, char \*key)` was added
   as shorthand for ``PyObject_DelItem(mapping, PyString_New(key))``.
 
 * File objects now manage their internal string buffer differently, increasing
@@ -1910,7 +1910,7 @@ Changes to Python's build process and to the C API include:
 
 * It's now possible to define class and static methods for a C extension type by
   setting either the :const:`METH_CLASS` or :const:`METH_STATIC` flags in a
-  method's :ctype:`PyMethodDef` structure.
+  method's :c:type:`PyMethodDef` structure.
 
 * Python now includes a copy of the Expat XML parser's source code, removing any
   dependence on a system version or local installation of Expat.
diff --git a/Doc/whatsnew/2.4.rst b/Doc/whatsnew/2.4.rst
index fadde50..3a12a79 100644
--- a/Doc/whatsnew/2.4.rst
+++ b/Doc/whatsnew/2.4.rst
@@ -469,7 +469,7 @@ PEP 327: Decimal Data Type
 ==========================
 
 Python has always supported floating-point (FP) numbers, based on the underlying
-C :ctype:`double` type, as a data type.  However, while most programming
+C :c:type:`double` type, as a data type.  However, while most programming
 languages provide a floating-point type, many people (even programmers) are
 unaware that floating-point numbers don't represent certain decimal fractions
 accurately.  The new :class:`Decimal` type can represent these fractions
@@ -498,7 +498,7 @@ mantissa is multiplied by 4 (2 to the power of the exponent 2); 1.25 \* 4 equals
 5.
 
 Modern systems usually provide floating-point support that conforms to a
-standard called IEEE 754.  C's :ctype:`double` type is usually implemented as a
+standard called IEEE 754.  C's :c:type:`double` type is usually implemented as a
 64-bit IEEE 754 number, which uses 52 bits of space for the mantissa.  This
 means that numbers can only be specified to 52 bits of precision.  If you're
 trying to represent numbers whose expansion repeats endlessly, the expansion is
@@ -736,7 +736,7 @@ display conventions that are localized to a particular country or language.
 However, the module was careful to not change the numeric locale because various
 functions in Python's implementation required that the numeric locale remain set
 to the ``'C'`` locale.  Often this was because the code was using the C
-library's :cfunc:`atof` function.
+library's :c:func:`atof` function.
 
 Not setting the numeric locale caused trouble for extensions that used third-
 party C libraries, however, because they wouldn't have the correct locale set.
@@ -746,11 +746,11 @@ numbers in the current locale.
 The solution described in the PEP is to add three new functions to the Python
 API that perform ASCII-only conversions, ignoring the locale setting:
 
-* :cfunc:`PyOS_ascii_strtod(str, ptr)`  and :cfunc:`PyOS_ascii_atof(str, ptr)`
-  both convert a string to a C :ctype:`double`.
+* :c:func:`PyOS_ascii_strtod(str, ptr)`  and :c:func:`PyOS_ascii_atof(str, ptr)`
+  both convert a string to a C :c:type:`double`.
 
-* :cfunc:`PyOS_ascii_formatd(buffer, buf_len, format, d)` converts a
-  :ctype:`double` to an ASCII string.
+* :c:func:`PyOS_ascii_formatd(buffer, buf_len, format, d)` converts a
+  :c:type:`double` to an ASCII string.
 
 The code for these functions came from the GLib library
 (http://library.gnome.org/devel/glib/stable/), whose developers kindly
@@ -938,7 +938,7 @@ Optimizations
 * The machinery for growing and shrinking lists was optimized for speed and for
   space efficiency.  Appending and popping from lists now runs faster due to more
   efficient code paths and less frequent use of the underlying system
-  :cfunc:`realloc`.  List comprehensions also benefit.   :meth:`list.extend` was
+  :c:func:`realloc`.  List comprehensions also benefit.   :meth:`list.extend` was
   also optimized and no longer converts its argument into a temporary list before
   extending the base list.  (Contributed by Raymond Hettinger.)
 
@@ -1445,34 +1445,34 @@ Build and C API Changes
 Some of the changes to Python's build process and to the C API are:
 
 * Three new convenience macros were added for common return values from
-  extension functions: :cmacro:`Py_RETURN_NONE`, :cmacro:`Py_RETURN_TRUE`, and
-  :cmacro:`Py_RETURN_FALSE`. (Contributed by Brett Cannon.)
+  extension functions: :c:macro:`Py_RETURN_NONE`, :c:macro:`Py_RETURN_TRUE`, and
+  :c:macro:`Py_RETURN_FALSE`. (Contributed by Brett Cannon.)
 
-* Another new macro, :cmacro:`Py_CLEAR(obj)`,  decreases the reference count of
+* Another new macro, :c:macro:`Py_CLEAR(obj)`,  decreases the reference count of
   *obj* and sets *obj* to the null pointer.  (Contributed by Jim Fulton.)
 
-* A new function, :cfunc:`PyTuple_Pack(N, obj1, obj2, ..., objN)`, constructs
+* A new function, :c:func:`PyTuple_Pack(N, obj1, obj2, ..., objN)`, constructs
   tuples from a variable length argument list of Python objects.  (Contributed by
   Raymond Hettinger.)
 
-* A new function, :cfunc:`PyDict_Contains(d, k)`, implements fast dictionary
+* A new function, :c:func:`PyDict_Contains(d, k)`, implements fast dictionary
   lookups without masking exceptions raised during the look-up process.
   (Contributed by Raymond Hettinger.)
 
-* The :cmacro:`Py_IS_NAN(X)` macro returns 1 if  its float or double argument
+* The :c:macro:`Py_IS_NAN(X)` macro returns 1 if  its float or double argument
   *X* is a NaN.   (Contributed by Tim Peters.)
 
 * C code can avoid unnecessary locking by using the new
-  :cfunc:`PyEval_ThreadsInitialized` function to tell  if any thread operations
+  :c:func:`PyEval_ThreadsInitialized` function to tell  if any thread operations
   have been performed.  If this function  returns false, no lock operations are
   needed. (Contributed by Nick Coghlan.)
 
-* A new function, :cfunc:`PyArg_VaParseTupleAndKeywords`, is the same as
-  :cfunc:`PyArg_ParseTupleAndKeywords` but takes a  :ctype:`va_list` instead of a
+* A new function, :c:func:`PyArg_VaParseTupleAndKeywords`, is the same as
+  :c:func:`PyArg_ParseTupleAndKeywords` but takes a  :c:type:`va_list` instead of a
   number of arguments. (Contributed by Greg Chapman.)
 
 * A new method flag, :const:`METH_COEXISTS`, allows a function defined in slots
-  to co-exist with a :ctype:`PyCFunction` having the same name.  This can halve
+  to co-exist with a :c:type:`PyCFunction` having the same name.  This can halve
   the access time for a method such as :meth:`set.__contains__`.  (Contributed by
   Raymond Hettinger.)
 
@@ -1486,8 +1486,8 @@ Some of the changes to Python's build process and to the C API are:
   though that processor architecture doesn't call that register "the TSC
   register".  (Contributed by Jeremy Hylton.)
 
-* The :ctype:`tracebackobject` type has been renamed to
-  :ctype:`PyTracebackObject`.
+* The :c:type:`tracebackobject` type has been renamed to
+  :c:type:`PyTracebackObject`.
 
 .. ======================================================================
 
diff --git a/Doc/whatsnew/2.5.rst b/Doc/whatsnew/2.5.rst
index c7f7d58..79d8ad2 100644
--- a/Doc/whatsnew/2.5.rst
+++ b/Doc/whatsnew/2.5.rst
@@ -870,31 +870,31 @@ to be able to remove the string-exception feature in a few releases.
 PEP 353: Using ssize_t as the index type
 ========================================
 
-A wide-ranging change to Python's C API, using a new  :ctype:`Py_ssize_t` type
-definition instead of :ctype:`int`,  will permit the interpreter to handle more
+A wide-ranging change to Python's C API, using a new  :c:type:`Py_ssize_t` type
+definition instead of :c:type:`int`,  will permit the interpreter to handle more
 data on 64-bit platforms. This change doesn't affect Python's capacity on 32-bit
 platforms.
 
-Various pieces of the Python interpreter used C's :ctype:`int` type to store
+Various pieces of the Python interpreter used C's :c:type:`int` type to store
 sizes or counts; for example, the number of items in a list or tuple were stored
-in an :ctype:`int`.  The C compilers for most 64-bit platforms still define
-:ctype:`int` as a 32-bit type, so that meant that lists could only hold up to
+in an :c:type:`int`.  The C compilers for most 64-bit platforms still define
+:c:type:`int` as a 32-bit type, so that meant that lists could only hold up to
 ``2**31 - 1`` = 2147483647 items. (There are actually a few different
 programming models that 64-bit C compilers can use -- see
 http://www.unix.org/version2/whatsnew/lp64_wp.html for a discussion -- but the
-most commonly available model leaves :ctype:`int` as 32 bits.)
+most commonly available model leaves :c:type:`int` as 32 bits.)
 
 A limit of 2147483647 items doesn't really matter on a 32-bit platform because
 you'll run out of memory before hitting the length limit. Each list item
 requires space for a pointer, which is 4 bytes, plus space for a
-:ctype:`PyObject` representing the item.  2147483647\*4 is already more bytes
+:c:type:`PyObject` representing the item.  2147483647\*4 is already more bytes
 than a 32-bit address space can contain.
 
 It's possible to address that much memory on a 64-bit platform, however.  The
 pointers for a list that size would only require 16 GiB of space, so it's not
 unreasonable that Python programmers might construct lists that large.
 Therefore, the Python interpreter had to be changed to use some type other than
-:ctype:`int`, and this will be a 64-bit type on 64-bit platforms.  The change
+:c:type:`int`, and this will be a 64-bit type on 64-bit platforms.  The change
 will cause incompatibilities on 64-bit machines, so it was deemed worth making
 the transition now, while the number of 64-bit users is still relatively small.
 (In 5 or 10 years, we may *all* be on 64-bit machines, and the transition would
@@ -902,15 +902,15 @@ be more painful then.)
 
 This change most strongly affects authors of C extension modules.   Python
 strings and container types such as lists and tuples  now use
-:ctype:`Py_ssize_t` to store their size.   Functions such as
-:cfunc:`PyList_Size`  now return :ctype:`Py_ssize_t`.  Code in extension modules
-may therefore need to have some variables changed to :ctype:`Py_ssize_t`.
+:c:type:`Py_ssize_t` to store their size.   Functions such as
+:c:func:`PyList_Size`  now return :c:type:`Py_ssize_t`.  Code in extension modules
+may therefore need to have some variables changed to :c:type:`Py_ssize_t`.
 
-The :cfunc:`PyArg_ParseTuple` and :cfunc:`Py_BuildValue` functions have a new
-conversion code, ``n``, for :ctype:`Py_ssize_t`.   :cfunc:`PyArg_ParseTuple`'s
-``s#`` and ``t#`` still output :ctype:`int` by default, but you can define the
-macro  :cmacro:`PY_SSIZE_T_CLEAN` before including :file:`Python.h`  to make
-them return :ctype:`Py_ssize_t`.
+The :c:func:`PyArg_ParseTuple` and :c:func:`Py_BuildValue` functions have a new
+conversion code, ``n``, for :c:type:`Py_ssize_t`.   :c:func:`PyArg_ParseTuple`'s
+``s#`` and ``t#`` still output :c:type:`int` by default, but you can define the
+macro  :c:macro:`PY_SSIZE_T_CLEAN` before including :file:`Python.h`  to make
+them return :c:type:`Py_ssize_t`.
 
 :pep:`353` has a section on conversion guidelines that  extension authors should
 read to learn about supporting 64-bit platforms.
@@ -954,8 +954,8 @@ interpreter will check that the type returned is correct, and raises a
 :exc:`TypeError` if this requirement isn't met.
 
 A corresponding :attr:`nb_index` slot was added to the C-level
-:ctype:`PyNumberMethods` structure to let C extensions implement this protocol.
-:cfunc:`PyNumber_Index(obj)` can be used in extension code to call the
+:c:type:`PyNumberMethods` structure to let C extensions implement this protocol.
+:c:func:`PyNumber_Index(obj)` can be used in extension code to call the
 :meth:`__index__` function and retrieve its result.
 
 
@@ -1179,7 +1179,7 @@ marked in the following list.
   (Contributed by Bob Ippolito at the NeedForSpeed sprint.)
 
 * The :mod:`re` module got a 1 or 2% speedup by switching to  Python's allocator
-  functions instead of the system's  :cfunc:`malloc` and :cfunc:`free`.
+  functions instead of the system's  :c:func:`malloc` and :c:func:`free`.
   (Contributed by Jack Diederich at the NeedForSpeed sprint.)
 
 * The code generator's peephole optimizer now performs simple constant folding
@@ -1203,7 +1203,7 @@ marked in the following list.
   Sean Reifschneider at the NeedForSpeed sprint.)
 
 * Importing now caches the paths tried, recording whether  they exist or not so
-  that the interpreter makes fewer  :cfunc:`open` and :cfunc:`stat` calls on
+  that the interpreter makes fewer  :c:func:`open` and :c:func:`stat` calls on
   startup. (Contributed by Martin von Löwis and Georg Brandl.)
 
   .. Patch 921466
@@ -1568,7 +1568,7 @@ complete list of changes, or look through the SVN logs for all the details.
   reporting ``('CPython', 'trunk', '45313:45315')``.
 
   This information is also available to C extensions via the
-  :cfunc:`Py_GetBuildInfo` function that returns a  string of build information
+  :c:func:`Py_GetBuildInfo` function that returns a  string of build information
   like this: ``"trunk:45355:45356M, Apr 13 2006, 07:42:19"``.   (Contributed by
   Barry Warsaw.)
 
@@ -1690,7 +1690,7 @@ attributes of the :class:`CDLL` object.   ::
    result = libc.printf("Line of output\n")
 
 Type constructors for the various C types are provided: :func:`c_int`,
-:func:`c_float`, :func:`c_double`, :func:`c_char_p` (equivalent to :ctype:`char
+:func:`c_float`, :func:`c_double`, :func:`c_char_p` (equivalent to :c:type:`char
 \*`), and so forth.  Unlike Python's types, the C versions are all mutable; you
 can assign to their :attr:`value` attribute to change the wrapped value.  Python
 integers and strings will be automatically converted to the corresponding C
@@ -1720,7 +1720,7 @@ attribute of the function object to  change this::
 ``ctypes.pythonapi`` object.  This object does *not*  release the global
 interpreter lock before calling a function, because the lock must be held when
 calling into the interpreter's code.   There's a :class:`py_object()` type
-constructor that will create a  :ctype:`PyObject \*` pointer.  A simple usage::
+constructor that will create a  :c:type:`PyObject \*` pointer.  A simple usage::
 
    import ctypes
 
@@ -2087,8 +2087,8 @@ Changes to Python's build process and to the C API include:
   http://scan.coverity.com for the statistics.
 
 * The largest change to the C API came from :pep:`353`, which modifies the
-  interpreter to use a :ctype:`Py_ssize_t` type definition instead of
-  :ctype:`int`.  See the earlier section :ref:`pep-353` for a discussion of this
+  interpreter to use a :c:type:`Py_ssize_t` type definition instead of
+  :c:type:`int`.  See the earlier section :ref:`pep-353` for a discussion of this
   change.
 
 * The design of the bytecode compiler has changed a great deal,  no longer
@@ -2113,10 +2113,10 @@ Changes to Python's build process and to the C API include:
   discusses the design.  To start learning about the code, read the definition of
   the various AST nodes in :file:`Parser/Python.asdl`.  A Python script reads this
   file and generates a set of C structure definitions in
-  :file:`Include/Python-ast.h`.  The :cfunc:`PyParser_ASTFromString` and
-  :cfunc:`PyParser_ASTFromFile`, defined in :file:`Include/pythonrun.h`, take
+  :file:`Include/Python-ast.h`.  The :c:func:`PyParser_ASTFromString` and
+  :c:func:`PyParser_ASTFromFile`, defined in :file:`Include/pythonrun.h`, take
   Python source as input and return the root of an AST representing the contents.
-  This AST can then be turned into a code object by :cfunc:`PyAST_Compile`.  For
+  This AST can then be turned into a code object by :c:func:`PyAST_Compile`.  For
   more information, read the source code, and then ask questions on python-dev.
 
   The AST code was developed under Jeremy Hylton's management, and implemented by
@@ -2138,55 +2138,55 @@ Changes to Python's build process and to the C API include:
 
   Note that this change means extension modules must be more careful when
   allocating memory.  Python's API has many different functions for allocating
-  memory that are grouped into families.  For example, :cfunc:`PyMem_Malloc`,
-  :cfunc:`PyMem_Realloc`, and :cfunc:`PyMem_Free` are one family that allocates
-  raw memory, while :cfunc:`PyObject_Malloc`, :cfunc:`PyObject_Realloc`, and
-  :cfunc:`PyObject_Free` are another family that's supposed to be used for
+  memory that are grouped into families.  For example, :c:func:`PyMem_Malloc`,
+  :c:func:`PyMem_Realloc`, and :c:func:`PyMem_Free` are one family that allocates
+  raw memory, while :c:func:`PyObject_Malloc`, :c:func:`PyObject_Realloc`, and
+  :c:func:`PyObject_Free` are another family that's supposed to be used for
   creating Python objects.
 
   Previously these different families all reduced to the platform's
-  :cfunc:`malloc` and :cfunc:`free` functions.  This meant  it didn't matter if
-  you got things wrong and allocated memory with the :cfunc:`PyMem` function but
-  freed it with the :cfunc:`PyObject` function.  With 2.5's changes to obmalloc,
+  :c:func:`malloc` and :c:func:`free` functions.  This meant  it didn't matter if
+  you got things wrong and allocated memory with the :c:func:`PyMem` function but
+  freed it with the :c:func:`PyObject` function.  With 2.5's changes to obmalloc,
   these families now do different things and mismatches will probably result in a
   segfault.  You should carefully test your C extension modules with Python 2.5.
 
-* The built-in set types now have an official C API.  Call :cfunc:`PySet_New`
-  and :cfunc:`PyFrozenSet_New` to create a new set, :cfunc:`PySet_Add` and
-  :cfunc:`PySet_Discard` to add and remove elements, and :cfunc:`PySet_Contains`
-  and :cfunc:`PySet_Size` to examine the set's state. (Contributed by Raymond
+* The built-in set types now have an official C API.  Call :c:func:`PySet_New`
+  and :c:func:`PyFrozenSet_New` to create a new set, :c:func:`PySet_Add` and
+  :c:func:`PySet_Discard` to add and remove elements, and :c:func:`PySet_Contains`
+  and :c:func:`PySet_Size` to examine the set's state. (Contributed by Raymond
   Hettinger.)
 
 * C code can now obtain information about the exact revision of the Python
-  interpreter by calling the  :cfunc:`Py_GetBuildInfo` function that returns a
+  interpreter by calling the  :c:func:`Py_GetBuildInfo` function that returns a
   string of build information like this: ``"trunk:45355:45356M, Apr 13 2006,
   07:42:19"``.   (Contributed by Barry Warsaw.)
 
 * Two new macros can be used to indicate C functions that are local to the
   current file so that a faster calling convention can be used.
-  :cfunc:`Py_LOCAL(type)` declares the function as returning a value of the
+  :c:func:`Py_LOCAL(type)` declares the function as returning a value of the
   specified *type* and uses a fast-calling qualifier.
-  :cfunc:`Py_LOCAL_INLINE(type)` does the same thing and also requests the
-  function be inlined.  If :cfunc:`PY_LOCAL_AGGRESSIVE` is defined before
+  :c:func:`Py_LOCAL_INLINE(type)` does the same thing and also requests the
+  function be inlined.  If :c:func:`PY_LOCAL_AGGRESSIVE` is defined before
   :file:`python.h` is included, a set of more aggressive optimizations are enabled
   for the module; you should benchmark the results to find out if these
   optimizations actually make the code faster.  (Contributed by Fredrik Lundh at
   the NeedForSpeed sprint.)
 
-* :cfunc:`PyErr_NewException(name, base, dict)` can now accept a tuple of base
+* :c:func:`PyErr_NewException(name, base, dict)` can now accept a tuple of base
   classes as its *base* argument.  (Contributed by Georg Brandl.)
 
-* The :cfunc:`PyErr_Warn` function for issuing warnings is now deprecated in
-  favour of :cfunc:`PyErr_WarnEx(category, message, stacklevel)` which lets you
+* The :c:func:`PyErr_Warn` function for issuing warnings is now deprecated in
+  favour of :c:func:`PyErr_WarnEx(category, message, stacklevel)` which lets you
   specify the number of stack frames separating this function and the caller.  A
-  *stacklevel* of 1 is the function calling :cfunc:`PyErr_WarnEx`, 2 is the
+  *stacklevel* of 1 is the function calling :c:func:`PyErr_WarnEx`, 2 is the
   function above that, and so forth.  (Added by Neal Norwitz.)
 
 * The CPython interpreter is still written in C, but  the code can now be
   compiled with a C++ compiler without errors.   (Implemented by Anthony Baxter,
   Martin von Löwis, Skip Montanaro.)
 
-* The :cfunc:`PyRange_New` function was removed.  It was never documented, never
+* The :c:func:`PyRange_New` function was removed.  It was never documented, never
   used in the core code, and had dangerously lax error checking.  In the unlikely
   case that your extensions were using it, you can replace it by something like
   the following::
@@ -2203,7 +2203,7 @@ Port-Specific Changes
 ---------------------
 
 * MacOS X (10.3 and higher): dynamic loading of modules now uses the
-  :cfunc:`dlopen` function instead of MacOS-specific functions.
+  :c:func:`dlopen` function instead of MacOS-specific functions.
 
 * MacOS X: an :option:`--enable-universalsdk` switch was added to the
   :program:`configure` script that compiles the interpreter as a universal binary
@@ -2259,15 +2259,15 @@ code:
   Setting  :attr:`rpc_paths` to ``None`` or an empty tuple disables  this path
   checking.
 
-* C API: Many functions now use :ctype:`Py_ssize_t`  instead of :ctype:`int` to
+* C API: Many functions now use :c:type:`Py_ssize_t`  instead of :c:type:`int` to
   allow processing more data on 64-bit machines.  Extension code may need to make
   the same change to avoid warnings and to support 64-bit machines.  See the
   earlier section :ref:`pep-353` for a discussion of this change.
 
 * C API:  The obmalloc changes mean that  you must be careful to not mix usage
-  of the :cfunc:`PyMem_\*` and :cfunc:`PyObject_\*` families of functions. Memory
-  allocated with  one family's :cfunc:`\*_Malloc` must be  freed with the
-  corresponding family's :cfunc:`\*_Free` function.
+  of the :c:func:`PyMem_\*` and :c:func:`PyObject_\*` families of functions. Memory
+  allocated with  one family's :c:func:`\*_Malloc` must be  freed with the
+  corresponding family's :c:func:`\*_Free` function.
 
 .. ======================================================================
 
diff --git a/Doc/whatsnew/2.6.rst b/Doc/whatsnew/2.6.rst
index fa237ca..be2c6ff 100644
--- a/Doc/whatsnew/2.6.rst
+++ b/Doc/whatsnew/2.6.rst
@@ -123,7 +123,7 @@ about features that will be removed in Python 3.0.  You can run code
 with this switch to see how much work will be necessary to port
 code to 3.0.  The value of this switch is available
 to Python code as the boolean variable :data:`sys.py3kwarning`,
-and to C extension code as :cdata:`Py_Py3kWarningFlag`.
+and to C extension code as :c:data:`Py_Py3kWarningFlag`.
 
 .. seealso::
 
@@ -979,10 +979,10 @@ can be used to include Unicode characters::
     print len(s)               # 12 Unicode characters
 
 At the C level, Python 3.0 will rename the existing 8-bit
-string type, called :ctype:`PyStringObject` in Python 2.x,
-to :ctype:`PyBytesObject`.  Python 2.6 uses ``#define``
-to support using the names :cfunc:`PyBytesObject`,
-:cfunc:`PyBytes_Check`, :cfunc:`PyBytes_FromStringAndSize`,
+string type, called :c:type:`PyStringObject` in Python 2.x,
+to :c:type:`PyBytesObject`.  Python 2.6 uses ``#define``
+to support using the names :c:func:`PyBytesObject`,
+:c:func:`PyBytes_Check`, :c:func:`PyBytes_FromStringAndSize`,
 and all the other functions and macros used with strings.
 
 Instances of the :class:`bytes` type are immutable just
@@ -1014,8 +1014,8 @@ and some of the methods of lists, such as :meth:`append`,
     bytearray(b'ABCde')
 
 There's also a corresponding C API, with
-:cfunc:`PyByteArray_FromObject`,
-:cfunc:`PyByteArray_FromStringAndSize`,
+:c:func:`PyByteArray_FromObject`,
+:c:func:`PyByteArray_FromStringAndSize`,
 and various other functions.
 
 .. seealso::
@@ -1134,7 +1134,7 @@ indicate that the external caller is done.
 
 .. XXX PyObject_GetBuffer not documented in c-api
 
-The *flags* argument to :cfunc:`PyObject_GetBuffer` specifies
+The *flags* argument to :c:func:`PyObject_GetBuffer` specifies
 constraints upon the memory returned.  Some examples are:
 
  * :const:`PyBUF_WRITABLE` indicates that the memory must be writable.
@@ -1145,7 +1145,7 @@ constraints upon the memory returned.  Some examples are:
    requests a C-contiguous (last dimension varies the fastest) or
    Fortran-contiguous (first dimension varies the fastest) array layout.
 
-Two new argument codes for :cfunc:`PyArg_ParseTuple`,
+Two new argument codes for :c:func:`PyArg_ParseTuple`,
 ``s*`` and ``z*``, return locked buffer objects for a parameter.
 
 .. seealso::
@@ -1639,7 +1639,7 @@ Some smaller changes made to the core Python language are:
   :meth:`__hash__` method inherited from a parent class, so
   assigning ``None`` was implemented as an override.  At the
   C level, extensions can set ``tp_hash`` to
-  :cfunc:`PyObject_HashNotImplemented`.
+  :c:func:`PyObject_HashNotImplemented`.
   (Fixed by Nick Coghlan and Amaury Forgeot d'Arc; :issue:`2235`.)
 
 * The :exc:`GeneratorExit` exception now subclasses
@@ -1709,7 +1709,7 @@ Optimizations
   By default, this change is only applied to types that are included with
   the Python core.  Extension modules may not necessarily be compatible with
   this cache,
-  so they must explicitly add :cmacro:`Py_TPFLAGS_HAVE_VERSION_TAG`
+  so they must explicitly add :c:macro:`Py_TPFLAGS_HAVE_VERSION_TAG`
   to the module's ``tp_flags`` field to enable the method cache.
   (To be compatible with the method cache, the extension module's code
   must not directly access and modify the ``tp_dict`` member of
@@ -2288,7 +2288,7 @@ changes, or look through the Subversion logs for all the details.
   (Contributed by Raymond Hettinger; :issue:`1861`.)
 
 * The :mod:`select` module now has wrapper functions
-  for the Linux :cfunc:`epoll` and BSD :cfunc:`kqueue` system calls.
+  for the Linux :c:func:`epoll` and BSD :c:func:`kqueue` system calls.
   :meth:`modify` method was added to the existing :class:`poll`
   objects; ``pollobj.modify(fd, eventmask)`` takes a file descriptor
   or file object and an event mask, modifying the recorded event mask
@@ -2321,13 +2321,13 @@ changes, or look through the Subversion logs for all the details.
   Calling ``signal.set_wakeup_fd(fd)`` sets a file descriptor
   to be used; when a signal is received, a byte is written to that
   file descriptor.  There's also a C-level function,
-  :cfunc:`PySignal_SetWakeupFd`, for setting the descriptor.
+  :c:func:`PySignal_SetWakeupFd`, for setting the descriptor.
 
   Event loops will use this by opening a pipe to create two descriptors,
   one for reading and one for writing.  The writable descriptor
   will be passed to :func:`set_wakeup_fd`, and the readable descriptor
   will be added to the list of descriptors monitored by the event loop via
-  :cfunc:`select` or :cfunc:`poll`.
+  :c:func:`select` or :c:func:`poll`.
   On receiving a signal, a byte will be written and the main event loop
   will be woken up, avoiding the need to poll.
 
@@ -2388,7 +2388,7 @@ changes, or look through the Subversion logs for all the details.
   has been updated from version 2.3.2 in Python 2.5 to
   version 2.4.1.
 
-* The :mod:`struct` module now supports the C99 :ctype:`_Bool` type,
+* The :mod:`struct` module now supports the C99 :c:type:`_Bool` type,
   using the format character ``'?'``.
   (Contributed by David Remahl.)
 
@@ -2396,7 +2396,7 @@ changes, or look through the Subversion logs for all the details.
   now have :meth:`terminate`, :meth:`kill`, and :meth:`send_signal` methods.
   On Windows, :meth:`send_signal` only supports the :const:`SIGTERM`
   signal, and all these methods are aliases for the Win32 API function
-  :cfunc:`TerminateProcess`.
+  :c:func:`TerminateProcess`.
   (Contributed by Christian Heimes.)
 
 * A new variable in the :mod:`sys` module, :attr:`float_info`, is an
@@ -2981,7 +2981,7 @@ Changes to Python's build process and to the C API include:
 
 * Python now must be compiled with C89 compilers (after 19
   years!).  This means that the Python source tree has dropped its
-  own implementations of :cfunc:`memmove` and :cfunc:`strerror`, which
+  own implementations of :c:func:`memmove` and :c:func:`strerror`, which
   are in the C89 standard library.
 
 * Python 2.6 can be built with Microsoft Visual Studio 2008 (version
@@ -3003,7 +3003,7 @@ Changes to Python's build process and to the C API include:
 
 * The new buffer interface, previously described in
   `the PEP 3118 section <#pep-3118-revised-buffer-protocol>`__,
-  adds :cfunc:`PyObject_GetBuffer` and :cfunc:`PyBuffer_Release`,
+  adds :c:func:`PyObject_GetBuffer` and :c:func:`PyBuffer_Release`,
   as well as a few other functions.
 
 * Python's use of the C stdio library is now thread-safe, or at least
@@ -3011,27 +3011,27 @@ Changes to Python's build process and to the C API include:
   bug occurred if one thread closed a file object while another thread
   was reading from or writing to the object.  In 2.6 file objects
   have a reference count, manipulated by the
-  :cfunc:`PyFile_IncUseCount` and :cfunc:`PyFile_DecUseCount`
+  :c:func:`PyFile_IncUseCount` and :c:func:`PyFile_DecUseCount`
   functions.  File objects can't be closed unless the reference count
-  is zero.  :cfunc:`PyFile_IncUseCount` should be called while the GIL
+  is zero.  :c:func:`PyFile_IncUseCount` should be called while the GIL
   is still held, before carrying out an I/O operation using the
-  ``FILE *`` pointer, and :cfunc:`PyFile_DecUseCount` should be called
+  ``FILE *`` pointer, and :c:func:`PyFile_DecUseCount` should be called
   immediately after the GIL is re-acquired.
   (Contributed by Antoine Pitrou and Gregory P. Smith.)
 
 * Importing modules simultaneously in two different threads no longer
   deadlocks; it will now raise an :exc:`ImportError`.  A new API
-  function, :cfunc:`PyImport_ImportModuleNoBlock`, will look for a
+  function, :c:func:`PyImport_ImportModuleNoBlock`, will look for a
   module in ``sys.modules`` first, then try to import it after
   acquiring an import lock.  If the import lock is held by another
   thread, an :exc:`ImportError` is raised.
   (Contributed by Christian Heimes.)
 
 * Several functions return information about the platform's
-  floating-point support.  :cfunc:`PyFloat_GetMax` returns
+  floating-point support.  :c:func:`PyFloat_GetMax` returns
   the maximum representable floating point value,
-  and :cfunc:`PyFloat_GetMin` returns the minimum
-  positive value.  :cfunc:`PyFloat_GetInfo` returns an object
+  and :c:func:`PyFloat_GetMin` returns the minimum
+  positive value.  :c:func:`PyFloat_GetInfo` returns an object
   containing more information from the :file:`float.h` file, such as
   ``"mant_dig"`` (number of digits in the mantissa), ``"epsilon"``
   (smallest difference between 1.0 and the next largest value
@@ -3039,7 +3039,7 @@ Changes to Python's build process and to the C API include:
   (Contributed by Christian Heimes; :issue:`1534`.)
 
 * C functions and methods that use
-  :cfunc:`PyComplex_AsCComplex` will now accept arguments that
+  :c:func:`PyComplex_AsCComplex` will now accept arguments that
   have a :meth:`__complex__` method.  In particular, the functions in the
   :mod:`cmath` module will now accept objects with this method.
   This is a backport of a Python 3.0 change.
@@ -3053,15 +3053,15 @@ Changes to Python's build process and to the C API include:
 * Many C extensions define their own little macro for adding
   integers and strings to the module's dictionary in the
   ``init*`` function.  Python 2.6 finally defines standard macros
-  for adding values to a module, :cmacro:`PyModule_AddStringMacro`
-  and :cmacro:`PyModule_AddIntMacro()`.  (Contributed by
+  for adding values to a module, :c:macro:`PyModule_AddStringMacro`
+  and :c:macro:`PyModule_AddIntMacro()`.  (Contributed by
   Christian Heimes.)
 
 * Some macros were renamed in both 3.0 and 2.6 to make it clearer that
   they are macros,
-  not functions.  :cmacro:`Py_Size()` became :cmacro:`Py_SIZE()`,
-  :cmacro:`Py_Type()` became :cmacro:`Py_TYPE()`, and
-  :cmacro:`Py_Refcnt()` became :cmacro:`Py_REFCNT()`.
+  not functions.  :c:macro:`Py_Size()` became :c:macro:`Py_SIZE()`,
+  :c:macro:`Py_Type()` became :c:macro:`Py_TYPE()`, and
+  :c:macro:`Py_Refcnt()` became :c:macro:`Py_REFCNT()`.
   The mixed-case macros are still available
   in Python 2.6 for backward compatibility.
   (:issue:`1629`)
@@ -3119,7 +3119,7 @@ Port-Specific Changes: Windows
 
 * The :mod:`socket` module's socket objects now have an
   :meth:`ioctl` method that provides a limited interface to the
-  :cfunc:`WSAIoctl` system interface.
+  :c:func:`WSAIoctl` system interface.
 
 * The :mod:`_winreg` module now has a function,
   :func:`ExpandEnvironmentStrings`,
@@ -3265,13 +3265,13 @@ that may require changes to your code:
   the implementation now explicitly checks for this case and raises
   an :exc:`ImportError`.
 
-* C API: the :cfunc:`PyImport_Import` and :cfunc:`PyImport_ImportModule`
+* C API: the :c:func:`PyImport_Import` and :c:func:`PyImport_ImportModule`
   functions now default to absolute imports, not relative imports.
   This will affect C extensions that import other modules.
 
 * C API: extension data types that shouldn't be hashable
   should define their ``tp_hash`` slot to
-  :cfunc:`PyObject_HashNotImplemented`.
+  :c:func:`PyObject_HashNotImplemented`.
 
 * The :mod:`socket` module exception :exc:`socket.error` now inherits
   from :exc:`IOError`.  Previously it wasn't a subclass of
diff --git a/Doc/whatsnew/2.7.rst b/Doc/whatsnew/2.7.rst
index b2725c9..d5ac782 100644
--- a/Doc/whatsnew/2.7.rst
+++ b/Doc/whatsnew/2.7.rst
@@ -149,8 +149,8 @@ A partial list of 3.1 features that were backported to 2.7:
   ``float(repr(x))`` recovers ``x``.
 * Float-to-string and string-to-float conversions are correctly rounded.
   The :func:`round` function is also now correctly rounded.
-* The :ctype:`PyCapsule` type, used to provide a C API for extension modules.
-* The :cfunc:`PyLong_AsLongAndOverflow` C API function.
+* The :c:type:`PyCapsule` type, used to provide a C API for extension modules.
+* The :c:func:`PyLong_AsLongAndOverflow` C API function.
 
 Other new Python3-mode warnings include:
 
@@ -313,7 +313,7 @@ added as a more powerful replacement for the
 This means Python now supports three different modules for parsing
 command-line arguments: :mod:`getopt`, :mod:`optparse`, and
 :mod:`argparse`.  The :mod:`getopt` module closely resembles the C
-library's :cfunc:`getopt` function, so it remains useful if you're writing a
+library's :c:func:`getopt` function, so it remains useful if you're writing a
 Python prototype that will eventually be rewritten in C.
 :mod:`optparse` becomes redundant, but there are no plans to remove it
 because there are many scripts still using it, and there's no
@@ -1484,7 +1484,7 @@ changes, or look through the Subversion logs for all the details.
 * The :mod:`ssl` module's :class:`ssl.SSLSocket` objects now support the
   buffer API, which fixed a test suite failure (fix by Antoine Pitrou;
   :issue:`7133`) and automatically set
-  OpenSSL's :cmacro:`SSL_MODE_AUTO_RETRY`, which will prevent an error
+  OpenSSL's :c:macro:`SSL_MODE_AUTO_RETRY`, which will prevent an error
   code being returned from :meth:`recv` operations that trigger an SSL
   renegotiation (fix by Antoine Pitrou; :issue:`8222`).
 
@@ -2053,49 +2053,49 @@ Changes to Python's build process and to the C API include:
   debugged doesn't hold the GIL; the macro now acquires it before printing.
   (Contributed by Victor Stinner; :issue:`3632`.)
 
-* :cfunc:`Py_AddPendingCall` is now thread-safe, letting any
+* :c:func:`Py_AddPendingCall` is now thread-safe, letting any
   worker thread submit notifications to the main Python thread.  This
   is particularly useful for asynchronous IO operations.
   (Contributed by Kristján Valur Jónsson; :issue:`4293`.)
 
-* New function: :cfunc:`PyCode_NewEmpty` creates an empty code object;
+* New function: :c:func:`PyCode_NewEmpty` creates an empty code object;
   only the filename, function name, and first line number are required.
   This is useful for extension modules that are attempting to
   construct a more useful traceback stack.  Previously such
-  extensions needed to call :cfunc:`PyCode_New`, which had many
+  extensions needed to call :c:func:`PyCode_New`, which had many
   more arguments.  (Added by Jeffrey Yasskin.)
 
-* New function: :cfunc:`PyErr_NewExceptionWithDoc` creates a new
-  exception class, just as the existing :cfunc:`PyErr_NewException` does,
+* New function: :c:func:`PyErr_NewExceptionWithDoc` creates a new
+  exception class, just as the existing :c:func:`PyErr_NewException` does,
   but takes an extra ``char *`` argument containing the docstring for the
   new exception class.  (Added by 'lekma' on the Python bug tracker;
   :issue:`7033`.)
 
-* New function: :cfunc:`PyFrame_GetLineNumber` takes a frame object
+* New function: :c:func:`PyFrame_GetLineNumber` takes a frame object
   and returns the line number that the frame is currently executing.
   Previously code would need to get the index of the bytecode
   instruction currently executing, and then look up the line number
   corresponding to that address.  (Added by Jeffrey Yasskin.)
 
-* New functions: :cfunc:`PyLong_AsLongAndOverflow` and
-  :cfunc:`PyLong_AsLongLongAndOverflow`  approximates a Python long
-  integer as a C :ctype:`long` or :ctype:`long long`.
+* New functions: :c:func:`PyLong_AsLongAndOverflow` and
+  :c:func:`PyLong_AsLongLongAndOverflow`  approximates a Python long
+  integer as a C :c:type:`long` or :c:type:`long long`.
   If the number is too large to fit into
   the output type, an *overflow* flag is set and returned to the caller.
   (Contributed by Case Van Horsen; :issue:`7528` and :issue:`7767`.)
 
 * New function: stemming from the rewrite of string-to-float conversion,
-  a new :cfunc:`PyOS_string_to_double` function was added.  The old
-  :cfunc:`PyOS_ascii_strtod` and :cfunc:`PyOS_ascii_atof` functions
+  a new :c:func:`PyOS_string_to_double` function was added.  The old
+  :c:func:`PyOS_ascii_strtod` and :c:func:`PyOS_ascii_atof` functions
   are now deprecated.
 
-* New function: :cfunc:`PySys_SetArgvEx` sets the value of
+* New function: :c:func:`PySys_SetArgvEx` sets the value of
   ``sys.argv`` and can optionally update ``sys.path`` to include the
   directory containing the script named by ``sys.argv[0]`` depending
   on the value of an *updatepath* parameter.
 
   This function was added to close a security hole for applications
-  that embed Python.  The old function, :cfunc:`PySys_SetArgv`, would
+  that embed Python.  The old function, :c:func:`PySys_SetArgv`, would
   always update ``sys.path``, and sometimes it would add the current
   directory.  This meant that, if you ran an application embedding
   Python in a directory controlled by someone else, attackers could
@@ -2103,8 +2103,8 @@ Changes to Python's build process and to the C API include:
   :file:`os.py`) that your application would then import and run.
 
   If you maintain a C/C++ application that embeds Python, check
-  whether you're calling :cfunc:`PySys_SetArgv` and carefully consider
-  whether the application should be using :cfunc:`PySys_SetArgvEx`
+  whether you're calling :c:func:`PySys_SetArgv` and carefully consider
+  whether the application should be using :c:func:`PySys_SetArgvEx`
   with *updatepath* set to false.
 
   Security issue reported as `CVE-2008-5983
@@ -2112,14 +2112,14 @@ Changes to Python's build process and to the C API include:
   discussed in :issue:`5753`, and fixed by Antoine Pitrou.
 
 * New macros: the Python header files now define the following macros:
-  :cmacro:`Py_ISALNUM`,
-  :cmacro:`Py_ISALPHA`,
-  :cmacro:`Py_ISDIGIT`,
-  :cmacro:`Py_ISLOWER`,
-  :cmacro:`Py_ISSPACE`,
-  :cmacro:`Py_ISUPPER`,
-  :cmacro:`Py_ISXDIGIT`,
-  and :cmacro:`Py_TOLOWER`, :cmacro:`Py_TOUPPER`.
+  :c:macro:`Py_ISALNUM`,
+  :c:macro:`Py_ISALPHA`,
+  :c:macro:`Py_ISDIGIT`,
+  :c:macro:`Py_ISLOWER`,
+  :c:macro:`Py_ISSPACE`,
+  :c:macro:`Py_ISUPPER`,
+  :c:macro:`Py_ISXDIGIT`,
+  and :c:macro:`Py_TOLOWER`, :c:macro:`Py_TOUPPER`.
   All of these functions are analogous to the C
   standard macros for classifying characters, but ignore the current
   locale setting, because in
@@ -2129,15 +2129,15 @@ Changes to Python's build process and to the C API include:
 
   .. XXX these macros don't seem to be described in the c-api docs.
 
-* Removed function: :cmacro:`PyEval_CallObject` is now only available
+* Removed function: :c:macro:`PyEval_CallObject` is now only available
   as a macro.  A function version was being kept around to preserve
   ABI linking compatibility, but that was in 1997; it can certainly be
   deleted by now.  (Removed by Antoine Pitrou; :issue:`8276`.)
 
-* New format codes: the :cfunc:`PyFormat_FromString`,
-  :cfunc:`PyFormat_FromStringV`, and :cfunc:`PyErr_Format` functions now
+* New format codes: the :c:func:`PyFormat_FromString`,
+  :c:func:`PyFormat_FromStringV`, and :c:func:`PyErr_Format` functions now
   accept ``%lld`` and ``%llu`` format codes for displaying
-  C's :ctype:`long long` types.
+  C's :c:type:`long long` types.
   (Contributed by Mark Dickinson; :issue:`7228`.)
 
 * The complicated interaction between threads and process forking has
@@ -2153,17 +2153,17 @@ Changes to Python's build process and to the C API include:
   Python 2.7 acquires the import lock before performing an
   :func:`os.fork`, and will also clean up any locks created using the
   :mod:`threading` module.  C extension modules that have internal
-  locks, or that call :cfunc:`fork()` themselves, will not benefit
+  locks, or that call :c:func:`fork()` themselves, will not benefit
   from this clean-up.
 
   (Fixed by Thomas Wouters; :issue:`1590864`.)
 
-* The :cfunc:`Py_Finalize` function now calls the internal
+* The :c:func:`Py_Finalize` function now calls the internal
   :func:`threading._shutdown` function; this prevents some exceptions from
   being raised when an interpreter shuts down.
   (Patch by Adam Olsen; :issue:`1722344`.)
 
-* When using the :ctype:`PyMemberDef` structure to define attributes
+* When using the :c:type:`PyMemberDef` structure to define attributes
   of a type, Python will no longer let you try to delete or set a
   :const:`T_STRING_INPLACE` attribute.
 
@@ -2190,7 +2190,7 @@ Changes to Python's build process and to the C API include:
   :issue:`6491`.)
 
 * The :program:`configure` script now checks for floating-point rounding bugs
-  on certain 32-bit Intel chips and defines a :cmacro:`X87_DOUBLE_ROUNDING`
+  on certain 32-bit Intel chips and defines a :c:macro:`X87_DOUBLE_ROUNDING`
   preprocessor definition.  No code currently uses this definition,
   but it's available if anyone wishes to use it.
   (Added by Mark Dickinson; :issue:`2937`.)
@@ -2211,7 +2211,7 @@ Changes to Python's build process and to the C API include:
 Capsules
 -------------------
 
-Python 3.1 adds a new C datatype, :ctype:`PyCapsule`, for providing a
+Python 3.1 adds a new C datatype, :c:type:`PyCapsule`, for providing a
 C API to an extension module.  A capsule is essentially the holder of
 a C ``void *`` pointer, and is made available as a module attribute; for
 example, the :mod:`socket` module's API is exposed as ``socket.CAPI``,
@@ -2221,10 +2221,10 @@ object, and then get the ``void *`` pointer, which will usually point
 to an array of pointers to the module's various API functions.
 
 There is an existing data type already used for this,
-:ctype:`PyCObject`, but it doesn't provide type safety.  Evil code
+:c:type:`PyCObject`, but it doesn't provide type safety.  Evil code
 written in pure Python could cause a segmentation fault by taking a
-:ctype:`PyCObject` from module A and somehow substituting it for the
-:ctype:`PyCObject` in module B.   Capsules know their own name,
+:c:type:`PyCObject` from module A and somehow substituting it for the
+:c:type:`PyCObject` in module B.   Capsules know their own name,
 and getting the pointer requires providing the name::
 
    void *vtable;
@@ -2237,15 +2237,15 @@ and getting the pointer requires providing the name::
    vtable = PyCapsule_GetPointer(capsule, "mymodule.CAPI");
 
 You are assured that ``vtable`` points to whatever you're expecting.
-If a different capsule was passed in, :cfunc:`PyCapsule_IsValid` would
+If a different capsule was passed in, :c:func:`PyCapsule_IsValid` would
 detect the mismatched name and return false.  Refer to
 :ref:`using-capsules` for more information on using these objects.
 
 Python 2.7 now uses capsules internally to provide various
-extension-module APIs, but the :cfunc:`PyCObject_AsVoidPtr` was
+extension-module APIs, but the :c:func:`PyCObject_AsVoidPtr` was
 modified to handle capsules, preserving compile-time compatibility
-with the :ctype:`CObject` interface.  Use of
-:cfunc:`PyCObject_AsVoidPtr` will signal a
+with the :c:type:`CObject` interface.  Use of
+:c:func:`PyCObject_AsVoidPtr` will signal a
 :exc:`PendingDeprecationWarning`, which is silent by default.
 
 Implemented in Python 3.1 and backported to 2.7 by Larry Hastings;
@@ -2272,7 +2272,7 @@ Port-Specific Changes: Windows
   tested and documented.
   (Implemented by Brian Curtin: :issue:`7347`.)
 
-* The new :cfunc:`_beginthreadex` API is used to start threads, and
+* The new :c:func:`_beginthreadex` API is used to start threads, and
   the native thread-local storage functions are now used.
   (Contributed by Kristján Valur Jónsson; :issue:`3582`.)
 
@@ -2280,7 +2280,7 @@ Port-Specific Changes: Windows
   can be the constants :const:`CTRL_C_EVENT`,
   :const:`CTRL_BREAK_EVENT`, or any integer.  The first two constants
   will send Control-C and Control-Break keystroke events to
-  subprocesses; any other value will use the :cfunc:`TerminateProcess`
+  subprocesses; any other value will use the :c:func:`TerminateProcess`
   API.  (Contributed by Miki Tebeka; :issue:`1220212`.)
 
 * The :func:`os.listdir` function now correctly fails
@@ -2453,17 +2453,17 @@ For C extensions:
   family of functions will now raise a :exc:`TypeError` exception
   instead of triggering a :exc:`DeprecationWarning` (:issue:`5080`).
 
-* Use the new :cfunc:`PyOS_string_to_double` function instead of the old
-  :cfunc:`PyOS_ascii_strtod` and :cfunc:`PyOS_ascii_atof` functions,
+* Use the new :c:func:`PyOS_string_to_double` function instead of the old
+  :c:func:`PyOS_ascii_strtod` and :c:func:`PyOS_ascii_atof` functions,
   which are now deprecated.
 
 For applications that embed Python:
 
-* The :cfunc:`PySys_SetArgvEx` function was added, letting
+* The :c:func:`PySys_SetArgvEx` function was added, letting
   applications close a security hole when the existing
-  :cfunc:`PySys_SetArgv` function was used.  Check whether you're
-  calling :cfunc:`PySys_SetArgv` and carefully consider whether the
-  application should be using :cfunc:`PySys_SetArgvEx` with
+  :c:func:`PySys_SetArgv` function was used.  Check whether you're
+  calling :c:func:`PySys_SetArgv` and carefully consider whether the
+  application should be using :c:func:`PySys_SetArgvEx` with
   *updatepath* set to false.
 
 .. ======================================================================
diff --git a/Doc/whatsnew/3.0.rst b/Doc/whatsnew/3.0.rst
index afec5fc..b7f7233 100644
--- a/Doc/whatsnew/3.0.rst
+++ b/Doc/whatsnew/3.0.rst
@@ -850,21 +850,21 @@ to the C API.
 
 * :pep:`3121`: Extension Module Initialization & Finalization.
 
-* :pep:`3123`: Making :cmacro:`PyObject_HEAD` conform to standard C.
+* :pep:`3123`: Making :c:macro:`PyObject_HEAD` conform to standard C.
 
 * No more C API support for restricted execution.
 
-* :cfunc:`PyNumber_Coerce`, :cfunc:`PyNumber_CoerceEx`,
-  :cfunc:`PyMember_Get`, and :cfunc:`PyMember_Set` C APIs are removed.
+* :c:func:`PyNumber_Coerce`, :c:func:`PyNumber_CoerceEx`,
+  :c:func:`PyMember_Get`, and :c:func:`PyMember_Set` C APIs are removed.
 
-* New C API :cfunc:`PyImport_ImportModuleNoBlock`, works like
-  :cfunc:`PyImport_ImportModule` but won't block on the import lock
+* New C API :c:func:`PyImport_ImportModuleNoBlock`, works like
+  :c:func:`PyImport_ImportModule` but won't block on the import lock
   (returning an error instead).
 
 * Renamed the boolean conversion C-level slot and method:
   ``nb_nonzero`` is now ``nb_bool``.
 
-* Removed :cmacro:`METH_OLDARGS` and :cmacro:`WITH_CYCLE_GC` from the C API.
+* Removed :c:macro:`METH_OLDARGS` and :c:macro:`WITH_CYCLE_GC` from the C API.
 
 .. ======================================================================
 
diff --git a/Doc/whatsnew/3.1.rst b/Doc/whatsnew/3.1.rst
index cebb829..64ae1c1 100644
--- a/Doc/whatsnew/3.1.rst
+++ b/Doc/whatsnew/3.1.rst
@@ -497,21 +497,21 @@ Changes to Python's build process and to the C API include:
 
   (Contributed by Mark Dickinson; :issue:`4258`.)
 
-* The :cfunc:`PyLong_AsUnsignedLongLong()` function now handles a negative
+* The :c:func:`PyLong_AsUnsignedLongLong()` function now handles a negative
   *pylong* by raising :exc:`OverflowError` instead of :exc:`TypeError`.
 
   (Contributed by Mark Dickinson and Lisandro Dalcrin; :issue:`5175`.)
 
-* Deprecated :cfunc:`PyNumber_Int`.  Use :cfunc:`PyNumber_Long` instead.
+* Deprecated :c:func:`PyNumber_Int`.  Use :c:func:`PyNumber_Long` instead.
 
   (Contributed by Mark Dickinson; :issue:`4910`.)
 
-* Added a new :cfunc:`PyOS_string_to_double` function to replace the
-  deprecated functions :cfunc:`PyOS_ascii_strtod` and :cfunc:`PyOS_ascii_atof`.
+* Added a new :c:func:`PyOS_string_to_double` function to replace the
+  deprecated functions :c:func:`PyOS_ascii_strtod` and :c:func:`PyOS_ascii_atof`.
 
   (Contributed by Mark Dickinson; :issue:`5914`.)
 
-* Added :ctype:`PyCapsule` as a replacement for the :ctype:`PyCObject` API.
+* Added :c:type:`PyCapsule` as a replacement for the :c:type:`PyCObject` API.
   The principal difference is that the new type has a well defined interface
   for passing typing safety information and a less complicated signature
   for calling a destructor.  The old type had a problematic API and is now
diff --git a/Doc/whatsnew/3.2.rst b/Doc/whatsnew/3.2.rst
index 533d038..084e105 100644
--- a/Doc/whatsnew/3.2.rst
+++ b/Doc/whatsnew/3.2.rst
@@ -577,8 +577,8 @@ require changes to your code:
   * "t#" format has been removed: use "s#" or "s*" instead
   * "w" and "w#" formats has been removed: use "w*" instead
 
-* The :ctype:`PyCObject` type, deprecated in 3.1, has been removed.  To wrap
-  opaque C pointers in Python objects, the :ctype:`PyCapsule` API should be used
+* The :c:type:`PyCObject` type, deprecated in 3.1, has been removed.  To wrap
+  opaque C pointers in Python objects, the :c:type:`PyCapsule` API should be used
   instead; the new type has a well-defined interface for passing typing safety
   information and a less complicated signature for calling a destructor.