Develop Reference

Refer reST label in python docstring

I want to refer to reST label in my python method docstring and am expecting Sphinx to generate appropriate links.
I tried the following which does not work for me.
myown.rst
.. my-label:
Some explanation ...
mymodule.py
def somefunc():
""" See :ref:`my-label`. """
... rest of the code ...
This produces "See my-label" as text in the generated html file while I am expecting it to create appropriate hyper-link.
I see this kind of references in python-docs (e.g. see https://docs.python.org/3/library/functions.html#classmethod ) and reference to Function definitions (which is generic explanation). However, this is not generated from docstrings (as can be seen from funcobject.c) .. so I am inclined to think that it is handcrafted rst !!

Based on comment from #mzjn - the section header was missing in the rst file. Adding that and regenerating fixes the issue.

Omit (or format) the value of a variable when documenting with Sphinx

I'm currently documenting a whole module with autodoc. However, I define several variables on the module level that contain long lists or dicts. They are included in the documentation together with the values, and the values are unformatted, so it looks like a 10-lines mess. What I want is for the docstring of those variables to be included, but for the values to be omitted or at least nicely formatted.
I've tried to exclude the variable from automodule directive and add it like that:
.. automodule:: foo.bar
:members:
:exclude-members: longstuff
.. py:data:: longstuff
This resulted in that only the variable name was included, whereas both the docstring and the value of longstuff were not present in the documentation.
How can I keep the docstring and get rid of the value (or have it nicely formatted) at the same time?

There is no simple configuration setting for omitting values of module level variables in the output. But you can do it by modifying the DataDocumenter.add_directive_header() method in autodoc.py. The crucial line in that method is
self.add_line(u' :annotation: = ' + objrepr, '<autodoc>')
where objrepr is the value.
The following monkey patch added to conf.py works for me:
from sphinx.ext.autodoc import ModuleLevelDocumenter, DataDocumenter
def add_directive_header(self, sig):
ModuleLevelDocumenter.add_directive_header(self, sig)
# Rest of original method ignored
DataDocumenter.add_directive_header = add_directive_header

Sphinx: list of functions in a module

I have some python modules containing mostly functions and a few classes. Each one is documented using sphinx-autodoc in a separate rst. What I want to do is to create a table or list of the module's contents at the top of each page, so for example, of mymodule.py is
def first():
'First function'
def second():
'Second function'
And mymodule.rst is
Page Contents
-------------
:create_page_contents_list:
Members
-------
.. automodule:: mymodule
:members:
Then the output should look something like this:
Page Contents
-------------
first
second
Members
-------
first()
First function
second()
Second function
The question how to do :create_page_contents_list:. I've have a look at using a TOC, but it seems that I would need to manually create an entry for each item. I've also looked at autosummary, but I still need to list the members. Any suggestions for automating this? I'd rather avoid third-party extensions.

You probably want something like the autosummary extension. The actual autosummary extension will not quite do what you want, though.
An example of how you might extend autosummary to auto-detect the contents of the module is given in this answer

Get "flat" member output for sphinx automodule

I'm using the Sphinx autodoc extension to document a module, and I'd like to get a flat list of the module's members in the documentation output.
I tried using the following:
.. automodule:: modname
:members:
However, there are two problems with this:
It includes the module's docstring, which I don't want here.
The name of each entry is prefixed with "modname.", which is completely redundant (since this page is specifically for documenting this module)
However, I haven't been able to find any config options that would let me selectively disable these two aspects while still getting the automatic listing of all of the module members.
My current plan is to just use autofunction (etc) and explicitly enumerate the members to be documented, but I'd still like to know if I missed an easy way to achieve what I originally wanted.
Update: I at least found a workaround for the second part: set add_module_names=False in conf.py. That's a global setting though, so it doesn't really answer my original question.

Looking at this answer to a similar question, I've found that you can use the autodoc-process-docstring event to remove the docstrings from modules appending the following code to your conf.py:
def skip_modules_docstring(app, what, name, obj, options, lines):
if what == 'module':
del lines[:]
def setup(app):
app.connect('autodoc-process-docstring', skip_modules_docstring)
Note that the del statement is needed because, according to the documentation, the modification to lines must happend in place (it you create a new object, it doesn't work).
Finally, you can also use name to filter the docstrings of just a few modules while keeping the ones from others.

How do I document a module in Python?

That's it. If you want to document a function or a class, you put a string just after the definition. For instance:
def foo():
"""This function does nothing."""
pass
But what about a module? How can I document what a file.py does?

Add your docstring as the first statement in the module.
"""
Your module's verbose yet thorough docstring.
"""
import foo
# ...
For packages, you can add your docstring to __init__.py.

For the packages, you can document it in __init__.py.
For the modules, you can add a docstring simply in the module file.
All the information is here: http://www.python.org/dev/peps/pep-0257/

Here is an Example Google Style Python Docstrings on how module can be documented. Basically there is an information about a module, how to execute it and information about module level variables and list of ToDo items.
"""Example Google style docstrings.
This module demonstrates documentation as specified by the `Google
Python Style Guide`_. Docstrings may extend over multiple lines.
Sections are created with a section header and a colon followed by a
block of indented text.
Example:
Examples can be given using either the ``Example`` or ``Examples``
sections. Sections support any reStructuredText formatting, including
literal blocks::
$ python example_google.py
Section breaks are created by resuming unindented text. Section breaks
are also implicitly created anytime a new section starts.
Attributes:
module_level_variable1 (int): Module level variables may be documented in
either the ``Attributes`` section of the module docstring, or in an
inline docstring immediately following the variable.
Either form is acceptable, but the two should not be mixed. Choose
one convention to document module level variables and be consistent
with it.
Todo:
* For module TODOs
* You have to also use ``sphinx.ext.todo`` extension
.. _Google Python Style Guide:
http://google.github.io/styleguide/pyguide.html
"""
module_level_variable1 = 12345
def my_function():
pass
...
...

You do it the exact same way. Put a string in as the first statement in the module.

It's easy, you just add a docstring at the top of the module.

For PyPI Packages:
If you add doc strings like this in your __init__.py file as seen below
"""
Please refer to the documentation provided in the README.md,
which can be found at gorpyter's PyPI URL: https://pypi.org/project/gorpyter/
"""
# <IMPORT_DEPENDENCIES>
def setup():
"""Verify your Python and R dependencies."""
Then you will receive this in everyday usage of the help function.
help(<YOUR_PACKAGE>)
DESCRIPTION
Please refer to the documentation provided in the README.md,
which can be found at gorpyter's PyPI URL: https://pypi.org/project/gorpyter/
FUNCTIONS
setup()
Verify your Python and R dependencies.
Note, that my help DESCRIPTION is triggered by having that first docstring at the very top of the file.