1 files changed, 3 insertions, 3 deletions
diff --git a/Doc/howto/descriptor.rst b/Doc/howto/descriptor.rst
index cdb6a8e..81bb8ca 100644
--- a/Doc/howto/descriptor.rst
+++ b/Doc/howto/descriptor.rst
@@ -97,7 +97,7 @@ transforms ``b.x`` into ``type(b).__dict__['x'].__get__(b, type(b))``.  The
 implementation works through a precedence chain that gives data descriptors
 priority over instance variables, instance variables priority over non-data
 descriptors, and assigns lowest priority to :meth:`__getattr__` if provided.  The
-full C implementation can be found in :cfunc:`PyObject_GenericGetAttr()` in
+full C implementation can be found in :c:func:`PyObject_GenericGetAttr()` in
 `Objects/object.c <http://svn.python.org/view/python/trunk/Objects/object.c?view=markup>`_\.
 
 For classes, the machinery is in :meth:`type.__getattribute__` which transforms
@@ -131,7 +131,7 @@ search using :meth:`object.__getattribute__`.
 Note, in Python 2.2, ``super(B, obj).m()`` would only invoke :meth:`__get__` if
 ``m`` was a data descriptor.  In Python 2.3, non-data descriptors also get
 invoked unless an old-style class is involved.  The implementation details are
-in :cfunc:`super_getattro()` in
+in :c:func:`super_getattro()` in
 `Objects/typeobject.c <http://svn.python.org/view/python/trunk/Objects/typeobject.c?view=markup>`_
 and a pure Python equivalent can be found in `Guido's Tutorial`_.
 
@@ -297,7 +297,7 @@ Running the interpreter shows how the function descriptor works in practice::
 
 The output suggests that bound and unbound methods are two different types.
 While they could have been implemented that way, the actual C implementation of
-:ctype:`PyMethod_Type` in
+:c:type:`PyMethod_Type` in
 `Objects/classobject.c <http://svn.python.org/view/python/trunk/Objects/classobject.c?view=markup>`_
 is a single object with two different representations depending on whether the
 :attr:`im_self` field is set or is *NULL* (the C equivalent of *None*).