-
-
Notifications
You must be signed in to change notification settings - Fork 168
DOC: Clarify recommendations regarding use of backticks #525
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 2 commits
13d4678
4895a4b
f4bb0f2
61c50b5
b39163a
9792831
4b3afe9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -175,8 +175,9 @@ respective types. | |||||
y | ||||||
Description of parameter `y` (with type not specified). | ||||||
|
||||||
Enclose variables in single backticks. The colon must be preceded | ||||||
by a space, or omitted if the type is absent. | ||||||
The colon must be preceded by a space, or omitted if the type is absent. | ||||||
When referring to a parameter in the description field or elsewhere within | ||||||
the same function or class docstring, enclose its name in single backticks. | ||||||
|
||||||
For the parameter types, be as precise as possible. Below are a | ||||||
few examples of parameters and their types. | ||||||
|
@@ -549,6 +550,8 @@ not explicitly imported, `.. plot::` can be used directly if | |||||
Documenting classes | ||||||
------------------- | ||||||
|
||||||
.. _classdoc: | ||||||
rossbar marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
||||||
Class docstring | ||||||
``````````````` | ||||||
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:: | |||||
Attributes | ||||||
---------- | ||||||
x : float | ||||||
The X coordinate. | ||||||
Description of attribute `x`. | ||||||
y : float | ||||||
The Y coordinate. | ||||||
Description of attribute `y`. | ||||||
|
||||||
When referring to an attribute in the description field or elsewhere within | ||||||
|
||||||
the same class docstring, enclose its name in single backticks. | ||||||
Attributes that are properties and have their own docstrings can be | ||||||
simply listed by name:: | ||||||
|
||||||
|
@@ -606,6 +611,8 @@ becomes useful to have an additional **Methods** section: | |||||
|
||||||
""" | ||||||
|
||||||
When referring to a method in the description field or elsewhere within | ||||||
the same class docstring, enclose its name in single backticks. | ||||||
If it is necessary to explain a private method (use with care!), it can | ||||||
be referred to in the :ref:`Extended Summary <extended_summary>` or the | ||||||
:ref:`Notes <notes>` section. | ||||||
|
@@ -690,11 +697,11 @@ belong in docstrings. | |||||
Other points to keep in mind | ||||||
---------------------------- | ||||||
* Equations : as discussed in the :ref:`Notes <notes>` section above, LaTeX | ||||||
formatting should be kept to a minimum. Often it's possible to show equations as | ||||||
Python code or pseudo-code instead, which is much more readable in a | ||||||
terminal. For inline display use double backticks (like ``y = np.sin(x)``). | ||||||
For display with blank lines above and below, use a double colon and indent | ||||||
the code, like:: | ||||||
formatting should be kept to a minimum. Often it's possible to show | ||||||
equations as Python code or pseudo-code instead, which is much more readable | ||||||
in a terminal. For inline display of code use double backticks, | ||||||
like ````y = np.sin(x)````. For display with blank lines above and below, | ||||||
rossbar marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
use a double colon and indent the code, like:: | ||||||
|
||||||
end of previous sentence:: | ||||||
|
||||||
|
@@ -717,7 +724,9 @@ Other points to keep in mind | |||||
(i.e. scalar types, sequence types), those arguments can be documented | ||||||
with type `array_like`. | ||||||
|
||||||
* Links : If you need to include hyperlinks in your docstring, note that | ||||||
* Links : Sphinx will automatically create hyperlinks to module, function, | ||||||
|
||||||
and class documentation if a recognized name is included within single | ||||||
backticks (e.g. `numpy`). If you need to include other hyperlinks, note that | ||||||
|
backticks (e.g. `numpy`). If you need to include other hyperlinks, note that | |
backticks (e.g. ```numpy``` renders as `numpy`). If you need to include other hyperlinks, note that |
But it is not rendering correctly right now.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where should users be referred?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestions on that to include here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me, the important distinction to make is: double-backticks is for monospace/code literals, single backticks are for references. If you want to attempt to link to something, use single backticks. If you just want monospace formatting without an attempted link, use double-backticks (the exception of course being numpydoc parameters).
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps this should be removed, but I wanted to mention it because it is the only reason I can see for using single backticks instead of double backticks. Otherwise, use of single backticks only causes problems with name collisions and renders in italics (which usually means "emphasis") where monospace (which means code) would be more clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd just remove this - it's probably more detail than most users are interested in (and is not necessarily correct - the actual rendering of e.g. italics is actually dictated by the sphinx theme).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps this would be simpler as "referring to any parameter of the function being documented", or something along that vein?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So basically remove "in the description field or...". That's probably fine. I think I wanted to point out specifically that this advice was not limited to references within the parameter documentation, but maybe it's better overall to just keep it simple.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd vote for simple as well, something like:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where else can the variable live? Returns? Class docs, etc.?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand. Is the question about what constitutes a "parameter", where else a parameter might be mentioned, or something else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another intent of the wording here was to try to clarify that parameters of other functions referred to in the current docstring are not subject to this rule. But I think @rossbar's wording does that implicitly, so I've changed it locally and will push shortly.