@@ -175,8 +175,9 @@ respective types.
175175 y
176176 Description of parameter `y` (with type not specified).
177177
178- Enclose variables in single backticks. The colon must be preceded
179- by a space, or omitted if the type is absent.
178+ The colon must be preceded by a space, or omitted if the type is absent.
179+ When referring to a parameter anywhere within the docstring, enclose its
180+ name in single backticks.
180181
181182For the parameter types, be as precise as possible. Below are a
182183few examples of parameters and their types.
@@ -549,6 +550,8 @@ not explicitly imported, `.. plot::` can be used directly if
549550Documenting classes
550551-------------------
551552
553+ .. _classdoc :
554+
552555Class docstring
553556```````````````
554557Use the same sections as outlined above (all except :ref: `Returns <returns >`
@@ -562,10 +565,12 @@ section, may be used to describe non-method attributes of the class::
562565 Attributes
563566 ----------
564567 x : float
565- The X coordinate .
568+ Description of attribute `x` .
566569 y : float
567- The Y coordinate .
570+ Description of attribute `y` .
568571
572+ When referring to an attribute anywhere within the docstring, enclose its
573+ name in single backticks.
569574Attributes that are properties and have their own docstrings can be
570575simply listed by name::
571576
@@ -606,6 +611,8 @@ becomes useful to have an additional **Methods** section:
606611
607612 """
608613
614+ When referring to a method anywhere within the docstring, enclose its
615+ name in single backticks.
609616If it is necessary to explain a private method (use with care!), it can
610617be referred to in the :ref: `Extended Summary <extended_summary >` or the
611618:ref: `Notes <notes >` section.
@@ -690,11 +697,11 @@ belong in docstrings.
690697Other points to keep in mind
691698----------------------------
692699* Equations : as discussed in the :ref: `Notes <notes >` section above, LaTeX
693- formatting should be kept to a minimum. Often it's possible to show equations as
694- Python code or pseudo-code instead, which is much more readable in a
695- terminal. For inline display use double backticks (like `` y = np.sin(x) ``).
696- For display with blank lines above and below, use a double colon and indent
697- the code, like::
700+ formatting should be kept to a minimum. Often it's possible to show
701+ equations as Python code or pseudo-code instead, which is much more readable
702+ in a terminal. For inline display of code, use double backticks
703+ like `` ``y = np.sin(x)`` ``. For display with blank lines above and below,
704+ use a double colon and indent the code, like::
698705
699706 end of previous sentence::
700707
@@ -717,9 +724,13 @@ Other points to keep in mind
717724 (i.e. scalar types, sequence types), those arguments can be documented
718725 with type `array_like `.
719726
720- * Links : If you need to include hyperlinks in your docstring, note that
721- some docstring sections are not parsed as standard reST, and in these
722- sections, numpydoc may become confused by hyperlink targets such as::
727+ * Links : Depending on project settings, hyperlinks to documentation of
728+ modules, classes, functions, methods, and attributes should automatically
729+ be created if a recognized name is included within single backticks (e.g.
730+ ```numpy` `` renders as :any: `numpy `). If you need to include other
731+ hyperlinks, note that some docstring sections are not parsed as standard
732+ reST, and in these sections, numpydoc may become confused by hyperlink
733+ targets such as::
723734
724735 .. _Example: http://www.example.com
725736
@@ -729,17 +740,31 @@ Other points to keep in mind
729740
730741 `Example <http://www.example.com>`_
731742
732-
733743Common reST concepts
734744--------------------
735745For paragraphs, indentation is significant and indicates indentation in the
736746output. New paragraphs are marked with a blank line.
737747
738- Use ``*italics* ``, ``**bold** `` and ````monospace`` `` if needed in any
739- explanations
740- (but not for variable names and doctest code or multi-line code).
741- Variable, module, function, and class names should be written between
742- single back-ticks (```numpy` ``).
748+ Use ``*italics* ``, ``**bold** `` if needed in any explanations.
749+
750+ Use of backticks in reST is a common point of confusion because it is different
751+ from markdown. In most flavors of markdown, single backticks are used for
752+ monospaced font; in reST, *double * backticks are for ``monospaced font ``,
753+ whereas the behavior of single backticks is defined by the default role. This
754+ leads to the following style recommendations:
755+
756+ - Module, class, function, method, and attribute names should render as
757+ hyperlinks in monospaced font (e.g. :any: `numpy `); depending on project
758+ settings, this may be accomplished simply be enclosing them in single
759+ backticks. If the hyperlink does not render as intended, explicitly
760+ include the appropriate role and/or namespace.
761+ - This guide continues to recommended that parameter names be enclosed within
762+ single backticks. Currently, this may cause parameter names to render
763+ improperly and cause warnings, but numpydoc will soon release a feature
764+ that causes them to render as monospaced hyperlinks to the parameter
765+ documentation.
766+ - All other text that is intended to render in ``monospaced `` font should be
767+ enclosed within ````double backticks`` ``.
743768
744769A more extensive example of reST markup can be found in `this example
745770document <http://docutils.sourceforge.net/docs/user/rst/demo.txt> `_;
0 commit comments