summaryrefslogtreecommitdiffstats
path: root/Doc/extending
diff options
context:
space:
mode:
authorSerhiy Storchaka <storchaka@gmail.com>2013-10-09 10:26:17 (GMT)
committerSerhiy Storchaka <storchaka@gmail.com>2013-10-09 10:26:17 (GMT)
commit0b68a2d67538703b13d4a824acf736f8ef103dad (patch)
tree24f48762bab91bc3e602a5bc54d346f1427a1a36 /Doc/extending
parent91aaeac0508feebc0b7aa436e634892a472e7e93 (diff)
downloadcpython-0b68a2d67538703b13d4a824acf736f8ef103dad.zip
cpython-0b68a2d67538703b13d4a824acf736f8ef103dad.tar.gz
cpython-0b68a2d67538703b13d4a824acf736f8ef103dad.tar.bz2
Issue 19195: Improved cross-references in C API documentation.
Diffstat (limited to 'Doc/extending')
-rw-r--r--Doc/extending/building.rst5
-rw-r--r--Doc/extending/extending.rst6
-rw-r--r--Doc/extending/newtypes.rst2
3 files changed, 7 insertions, 6 deletions
diff --git a/Doc/extending/building.rst b/Doc/extending/building.rst
index f4d95b2..08b0cc2 100644
--- a/Doc/extending/building.rst
+++ b/Doc/extending/building.rst
@@ -58,8 +58,9 @@ distutils; this section explains building extension modules only.
It is common to pre-compute arguments to :func:`setup`, to better structure the
driver script. In the example above, the\ ``ext_modules`` argument to
:func:`setup` is a list of extension modules, each of which is an instance of
-the :class:`Extension`. In the example, the instance defines an extension named
-``demo`` which is build by compiling a single source file, :file:`demo.c`.
+the :class:`~distutils.extension.Extension`. In the example, the instance
+defines an extension named ``demo`` which is build by compiling a single source
+file, :file:`demo.c`.
In many cases, building an extension is more complex, since additional
preprocessor defines and libraries may be needed. This is demonstrated in the
diff --git a/Doc/extending/extending.rst b/Doc/extending/extending.rst
index a559b56..a3bf265 100644
--- a/Doc/extending/extending.rst
+++ b/Doc/extending/extending.rst
@@ -860,9 +860,9 @@ the cycle itself.
The cycle detector is able to detect garbage cycles and can reclaim them so long
as there are no finalizers implemented in Python (:meth:`__del__` methods).
When there are such finalizers, the detector exposes the cycles through the
-:mod:`gc` module (specifically, the
-``garbage`` variable in that module). The :mod:`gc` module also exposes a way
-to run the detector (the :func:`collect` function), as well as configuration
+:mod:`gc` module (specifically, the :attr:`~gc.garbage` variable in that module).
+The :mod:`gc` module also exposes a way to run the detector (the
+:func:`~gc.collect` function), as well as configuration
interfaces and the ability to disable the detector at runtime. The cycle
detector is considered an optional component; though it is included by default,
it can be disabled at build time using the :option:`--without-cycle-gc` option
diff --git a/Doc/extending/newtypes.rst b/Doc/extending/newtypes.rst
index f65c183..f484ba4 100644
--- a/Doc/extending/newtypes.rst
+++ b/Doc/extending/newtypes.rst
@@ -137,7 +137,7 @@ This is so that Python knows how much memory to allocate when you call
If you want your type to be subclassable from Python, and your type has the same
:c:member:`~PyTypeObject.tp_basicsize` as its base type, you may have problems with multiple
inheritance. A Python subclass of your type will have to list your type first
- in its :attr:`__bases__`, or else it will not be able to call your type's
+ in its :attr:`~class.__bases__`, or else it will not be able to call your type's
:meth:`__new__` method without getting an error. You can avoid this problem by
ensuring that your type has a larger value for :c:member:`~PyTypeObject.tp_basicsize` than its
base type does. Most of the time, this will be true anyway, because either your