Replaced the text in reference/extension_types.rst by links to the...

Replaced the text in reference/extension_types.rst by links to the corresponding sections in the userguide.

docs/src/userguide/extension_types.rst

@@ -194,6 +194,7 @@ The old behavior is always available by passing a tuple as the second parameter:
     print isinstance(sh, Shrubbery)     # Check the type of sh
     print isinstance(sh, (Shrubbery,))  # Check sh.__class__
 
+.. _extension_types_and_none:
 
 Extension types and None
 =========================
@@ -263,6 +264,8 @@ counterparts. There is a :ref:`separate page <special-methods>` devoted to this
 read it carefully before attempting to use any special methods in your
 extension types.
 
+.. _properties:
+
 Properties
 ============
 
@@ -356,6 +359,8 @@ when it is deleted.::
     We don't have: ['camembert', 'cheddar']
     We don't have: []
 
+.. _subclassing:
+
 Subclassing
 =============
 
@@ -462,6 +467,7 @@ compatible types.::
             p.ptr = ptr
             return p
 
+.. _forward_declaring_extension_types:
 
 Forward-declaring extension types
 ===================================
@@ -526,6 +532,7 @@ statically sized freelist of ``N`` instances for a given type.  Example::
     penguin = None
     penguin = Penguin('fish 2')  # does not need to allocate memory!
 
+.. _making_extension_types_weak_referenceable:
 
 Making extension types weak-referenceable
 ==========================================
@@ -618,6 +625,8 @@ declaration makes an extension type defined in external C code available to a
 Cython module. A public extension type declaration makes an extension type
 defined in a Cython module available to external C code.
 
+.. _external_extension_types:
+
 External extension types
 ------------------------
 
@@ -673,6 +682,8 @@ built-in complex object.::
        declaration is inside a :keyword:`cdef` extern from block, you only need to
        declare those C members which you wish to access.
 
+.. _name_specification_clause:
+
 Name specification clause
 -------------------------
 
@@ -728,6 +739,8 @@ which corresponds to the implicit import statement::
 
       from My.Nested.Package import Spam as Yummy
 
+.. _types_names_vs_constructor_names:
+
 Type names vs. constructor names
 --------------------------------
 
@@ -758,6 +771,8 @@ then Yummy becomes both the type name and a name for the constructor. Again,
 there are other ways that you could get hold of the constructor, but only
 Yummy is usable as a type name.
 
+.. _public:
+
 Public extension types
 ======================
 

docs/src/userguide/special_methods.rst

@@ -13,12 +13,16 @@ mention.
     with the :keyword:`cdef class` statement. It doesn't apply to classes defined with the
     Python :keyword:`class` statement, where the normal Python rules apply.
 
+.. _declaration:
+
 Declaration
 ------------
 Special methods of extension types must be declared with :keyword:`def`, not
 :keyword:`cdef`. This does not impact their performance--Python uses different
 calling conventions to invoke these special methods.
 
+.. _docstrings:
+
 Docstrings
 -----------
 
@@ -28,6 +32,8 @@ won't show up in the corresponding :attr:`__doc__` attribute at run time. (This
 seems to be is a Python limitation -- there's nowhere in the `PyTypeObject`
 data structure to put such docstrings.)
 
+.. _initialisation_methods:
+
 Initialisation methods: :meth:`__cinit__` and :meth:`__init__`
 ---------------------------------------------------------------
 There are two methods concerned with initialising the object.
@@ -90,6 +96,8 @@ complaining about the signature mismatch.
 
 .. [#] http://docs.python.org/reference/datamodel.html#object.__new__
 
+.. _finalization_method:
+
 Finalization method: :meth:`__dealloc__`
 ----------------------------------------
 
@@ -117,6 +125,8 @@ executed unless they are explicitly called by the subclass.
 
 .. Note:: There is no :meth:`__del__` method for extension types.
 
+.. _arithmetic_methods:
+
 Arithmetic methods
 -------------------
 
@@ -135,6 +145,8 @@ This also applies to the in-place arithmetic method :meth:`__ipow__`. It doesn't
 to any of the other in-place methods (:meth:`__iadd__`, etc.) which always
 take `self` as the first argument.
 
+.. _righ_comparisons:
+
 Rich comparisons
 -----------------
 
@@ -167,6 +179,8 @@ Depending on the application, one way or the other may be better:
 
   These constants can be cimported from the ``cpython.object`` module.
 
+.. _the__next__method:
+
 The :meth:`__next__` method
 ----------------------------