Fix more links to PyMODINIT_FUNC

Author: vstinner

Doc/extending/extending.rst

@@ -242,7 +242,7 @@ needed to ensure that it will not be discarded, causing :c:data:`!SpamError` to
 become a dangling pointer. Should it become a dangling pointer, C code which
 raises the exception could cause a core dump or other unintended side effects.
 
-We discuss the use of :c:macro:`PyMODINIT_FUNC` as a function return type later in this
+We discuss the use of :c:macro:`!PyMODINIT_FUNC` as a function return type later in this
 sample.
 
 The :exc:`!spam.error` exception can be raised in your extension module using a
@@ -363,7 +363,7 @@ only non-\ ``static`` item defined in the module file::
        return PyModule_Create(&spammodule);
    }
 
-Note that :c:macro:`PyMODINIT_FUNC` declares the function as ``PyObject *`` return type,
+Note that :c:macro:`!PyMODINIT_FUNC` declares the function as ``PyObject *`` return type,
 declares any special linkage declarations required by the platform, and for C++
 declares the function as ``extern "C"``.
 

Doc/whatsnew/2.3.rst

@@ -1888,7 +1888,7 @@ Changes to Python's build process and to the C API include:
 
 * 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 :c:macro:`PyMODINIT_FUNC`, while the Python core will
+  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