Difference between revisions of "Sphinx gotchas"
(→Napoleon: add gotcha: available docstring sections) |
(→Napoleon: add gotcha: Returns section) |
||
Line 88: | Line 88: | ||
See the [http://www.sphinx-doc.org/en/stable/ext/napoleon.html#docstring-sections list of docstring sections] supported by Napoleon. Everything else will ''not'' be typeset with a dedicated heading, you will have to do so explicitly using reStructuredText markup. | See the [http://www.sphinx-doc.org/en/stable/ext/napoleon.html#docstring-sections list of docstring sections] supported by Napoleon. Everything else will ''not'' be typeset with a dedicated heading, you will have to do so explicitly using reStructuredText markup. | ||
+ | === Returns === | ||
+ | |||
+ | In Returns section you need to use ":" carefully as, if present, it will be interpreted as a separator between return type and description. Also, the description of return value should not start on the same line of "Returns:", but on the subsequent one, indented. | ||
+ | |||
+ | Good: | ||
+ | <pre> | ||
+ | Returns: | ||
+ | this works, a dict with keys | ||
+ | |||
+ | - foo | ||
+ | - bar | ||
+ | </pre> | ||
+ | |||
+ | Bad: | ||
+ | <pre> | ||
+ | Returns: | ||
+ | this does not work, a dict with keys: | ||
+ | |||
+ | - foo | ||
+ | - bar | ||
+ | <pre> | ||
+ | |||
+ | Good: | ||
+ | <pre> | ||
+ | Returns: | ||
+ | dicts: this works again, a dict with keys: | ||
+ | |||
+ | - foo | ||
+ | - bar | ||
+ | </pre> | ||
+ | |||
+ | Bad: | ||
+ | <pre> | ||
+ | Returns: this is not good either, you need to start a paragraph | ||
+ | </pre> | ||
[[Category:Guidelines]] | [[Category:Guidelines]] | ||
[[Category:Software development]] | [[Category:Software development]] | ||
[[Category:Python]] | [[Category:Python]] |
Revision as of 13:26, 7 September 2017
Here is a list of common gotchas when formatting Python docstrings for Sphinx and the Napoleon style.
Sphinx
Lists
All sorts of lists require an empty line before the first bullet and after the last one, to be properly interpreted as list. No indentation is required for list elements w.r.t. surrounding text, and line continuations should be indented like the first character after the bullet
Good:
this is some text preceding the list - foo - bar - baz - this is a rather long-ish paragraph inserted in the list with line continuation - qux this is some text following the list
Bad:
this is a bad example that will not be interpreted as a list preceding text - foo - bar - baz following text
Good:
surrounding text - foo - nested lists also requires empty lines - inner list 1 - inner list 2 - outer list continues here surrounding text
Bad:
- foo - nested lists also requires empty lines - inner list 1 - inner list 2 - outer list continues here
Verbatim source code
Verbatim code blocks, e.g., for code examples, requires double colon at the end of a line, then an empty line, and then the code block itself, indented:
a nice example of python code follows:: def foo(bar, baz): qux = bar + baz return qux here we can restart text flow
Inline code samples use double backquotes, and not single ones.
Good:
you have to instantiate the method ``def foo(bar): pass`` in order to use this abstract class
Bad:
you have to instantiate the method `def foo(bar): pass` in order to use this abstract class
Napoleon
Docstring sections
See the list of docstring sections supported by Napoleon. Everything else will not be typeset with a dedicated heading, you will have to do so explicitly using reStructuredText markup.
Returns
In Returns section you need to use ":" carefully as, if present, it will be interpreted as a separator between return type and description. Also, the description of return value should not start on the same line of "Returns:", but on the subsequent one, indented.
Good:
Returns: this works, a dict with keys - foo - bar
Bad:
Returns: this does not work, a dict with keys: - foo - bar <pre> Good: <pre> Returns: dicts: this works again, a dict with keys: - foo - bar
Bad:
Returns: this is not good either, you need to start a paragraph