Skip to content

Commit b81aa84

Browse files
authored
Merge pull request realpython#712 from Michael-F-Bryan/docstrings
Wrote up a couple examples for docstrings
2 parents e8c377a + 10defd7 commit b81aa84

File tree

1 file changed

+105
-2
lines changed

1 file changed

+105
-2
lines changed

docs/writing/documentation.rst

Lines changed: 105 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -65,6 +65,11 @@ There is also **great**, **free** hosting for your Sphinx_ docs:
6565
your source repository so that rebuilding your documentation will
6666
happen automatically.
6767

68+
When run, Sphinx_ will import your code and using Python's introspection
69+
features it will extract all function, method and class signatures. It will
70+
also extract the accompanying docstrings, and compile it all into well
71+
structured and easily readable documentation for your project.
72+
6873
.. note::
6974

7075
Sphinx is famous for its API generation, but it also works well
@@ -127,6 +132,30 @@ Some tools use docstrings to embed more-than-documentation behavior,
127132
such as unit test logic. Those can be nice, but you won't ever go
128133
wrong with vanilla "here's what this does."
129134

135+
Tools like Sphinx_ will parse your docstrings as reStructuredText and render it
136+
correctly as HTML. This makes it very easy to embed snippets of example code in
137+
a project's documentation.
138+
139+
Additionally, Doctest_ will read all embedded docstrings that look like input
140+
from the Python commandline (prefixed with ">>>") and run them, checking to see
141+
if the output of the command matches the text on the following line. This
142+
allows developers to embed real examples and usage of functions alongside
143+
their source code, and as a side effect, it also ensures that their code is
144+
tested and works.
145+
146+
::
147+
148+
def my_function(a, b):
149+
"""
150+
>>> my_function(2, 3)
151+
6
152+
>>> my_function('a', 3)
153+
'aaa'
154+
"""
155+
return a * b
156+
157+
.. _Doctest: https://docs.python.org/3/library/doctest.html
158+
130159
Docstrings versus Block comments
131160
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
132161

@@ -141,8 +170,82 @@ comment block is a programmer's note. The docstring describes the
141170
"""Returns the square root of self times self."""
142171
...
143172
144-
.. see also:: Further reading on docstrings: :pep:`257`
145-
173+
Unlike block comments, docstrings are built into the Python language itself.
174+
This means you can use all of Python's powerful introspection capabilities to
175+
access docstrings at runtime, compared with comments which are optimised out.
176+
Docstrings are accessible from both the `__doc__` dunder attribute for almost
177+
every Python object, as well as with the built in `help()` function.
178+
179+
While block comments are usually used to explain *what* a section of code is
180+
doing, or the specifics of an algorithm, docstrings are more intended for
181+
explaining to other users of your code (or you in 6 months time) *how* a
182+
particular function can be used and the general purpose of a function, class,
183+
or module.
184+
185+
Writing Docstrings
186+
~~~~~~~~~~~~~~~~~~
187+
188+
Depending on the complexity of the function, method, or class being written, a
189+
one-line docstring may be perfectly appropriate. These are generally used for
190+
really obvious cases, such as::
191+
192+
def add(a, b):
193+
"""Add two numbers and return the result."""
194+
return a + b
195+
196+
The docstring should describe the function in a way that is easy to understand.
197+
For simple cases like trivial functions and classes, simply embedding the
198+
function's signature (i.e. `add(a, b) -> result`) in the docstring is
199+
unnecessary. This is because with Python's `inspect` module, it is already
200+
quite easy to find this information if needed, and it is also readily available
201+
by reading the source code.
202+
203+
In larger or more complex projects however, it is often a good idea to give
204+
more information about a function, what it does, any exceptions it may raise,
205+
what it returns, or relevant details about the parameters.
206+
207+
For more detailed documentation of code a popular style is the one used for the
208+
Numpy project, often called `Numpy style`_ docstrings. While it can take up a
209+
few more lines the previous example, it allows the developer to include a lot
210+
more information about a method, function, or class. ::
211+
212+
def random_number_generator(arg1, arg2):
213+
"""
214+
Summary line.
215+
216+
Extended description of function.
217+
218+
Parameters
219+
----------
220+
arg1 : int
221+
Description of arg1
222+
arg2 : str
223+
Description of arg2
224+
225+
Returns
226+
-------
227+
int
228+
Description of return value
229+
230+
"""
231+
return 42
232+
233+
The `sphinx.ext.napoleon`_ plugin allows Sphinx to parse this style of
234+
docstrings, making it easy to incorporate NumPy style docstrings into your
235+
project.
236+
237+
At the end of the day, it doesn't really matter what style is used for writing
238+
docstrings, their purpose is to serve as documentation for anyone who may need
239+
to read or make changes to your code. As long as it is correct, understandable
240+
and gets the relevant points across then it has done the job it was designed to
241+
do.
242+
243+
244+
For further reading on docstrings, feel free to consult :pep:`257`
245+
246+
.. _thomas-cokelaer.info: http://thomas-cokelaer.info/tutorials/sphinx/docstring_python.html
247+
.. _sphinx.ext.napoleon: https://sphinxcontrib-napoleon.readthedocs.io/
248+
.. _`NumPy style`: http://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_numpy.html
146249

147250
Other Tools
148251
-----------

0 commit comments

Comments
 (0)