@@ -175,8 +175,9 @@ respective types.
175
175
y
176
176
Description of parameter `y` (with type not specified).
177
177
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.
180
181
181
182
For the parameter types, be as precise as possible. Below are a
182
183
few examples of parameters and their types.
@@ -549,6 +550,8 @@ not explicitly imported, `.. plot::` can be used directly if
549
550
Documenting classes
550
551
-------------------
551
552
553
+ .. _classdoc :
554
+
552
555
Class docstring
553
556
```````````````
554
557
Use 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::
562
565
Attributes
563
566
----------
564
567
x : float
565
- The X coordinate .
568
+ Description of attribute `x` .
566
569
y : float
567
- The Y coordinate .
570
+ Description of attribute `y` .
568
571
572
+ When referring to an attribute anywhere within the docstring, enclose its
573
+ name in single backticks.
569
574
Attributes that are properties and have their own docstrings can be
570
575
simply listed by name::
571
576
@@ -606,6 +611,8 @@ becomes useful to have an additional **Methods** section:
606
611
607
612
"""
608
613
614
+ When referring to a method anywhere within the docstring, enclose its
615
+ name in single backticks.
609
616
If it is necessary to explain a private method (use with care!), it can
610
617
be referred to in the :ref: `Extended Summary <extended_summary >` or the
611
618
:ref: `Notes <notes >` section.
@@ -690,11 +697,11 @@ belong in docstrings.
690
697
Other points to keep in mind
691
698
----------------------------
692
699
* 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::
698
705
699
706
end of previous sentence::
700
707
@@ -717,9 +724,13 @@ Other points to keep in mind
717
724
(i.e. scalar types, sequence types), those arguments can be documented
718
725
with type `array_like `.
719
726
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::
723
734
724
735
.. _Example: http://www.example.com
725
736
@@ -729,17 +740,31 @@ Other points to keep in mind
729
740
730
741
`Example <http://www.example.com>`_
731
742
732
-
733
743
Common reST concepts
734
744
--------------------
735
745
For paragraphs, indentation is significant and indicates indentation in the
736
746
output. New paragraphs are marked with a blank line.
737
747
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`` ``.
743
768
744
769
A more extensive example of reST markup can be found in `this example
745
770
document <http://docutils.sourceforge.net/docs/user/rst/demo.txt> `_;
0 commit comments