Additional Markup Constructs
Sphinx adds a lot of new directives and interpreted text roles to standard reST markup. This section contains the reference material for these facilities. Documentation for "standard" reST constructs is not included here, though they are used in the Python documentation.
This is just an overview of Sphinx' extended markup capabilities; full coverage can be found in its own documentation.
The markup described in this section is used to provide information about a module being documented. Each module should be documented in its own file. Normally this markup appears after the title heading of that file; a typical file might start like this:
:mod:`parrot` -- Dead parrot access =================================== .. module:: parrot :platform: Unix, Windows :synopsis: Analyze and reanimate dead parrots. .. moduleauthor:: Eric Cleese <email@example.com> .. moduleauthor:: John Idle <firstname.lastname@example.org>
As you can see, the module-specific markup consists of two directives, the module directive and the moduleauthor directive.
It is important to make the section title of a module-describing file meaningful since that value will be inserted in the table-of-contents trees in overview files.
There are a number of directives used to describe specific features provided by modules. Each directive requires one or more signatures to provide basic information about what is being described, and the content should be the description. The basic version makes entries in the general index; if no index entry is desired, you can give the directive option flag :noindex:. The following example shows all of the features of this directive type:
.. function:: spam(eggs) ham(eggs) :noindex: Spam or ham the foo.
The signatures of object methods or data attributes should not include the class name, but be nested in a class directive. The generated files will reflect this nesting, and the target identifiers (for HTML output) will use both the class and method name, to enable consistent cross-references. If you describe methods belonging to an abstract protocol such as context managers, use a class directive with a (pseudo-)type name too to make the index entries more informative.
The directives are:
There is also a generic version of these directives:
Showing code examples
Examples of Python source code or interactive sessions are represented using standard reST literal blocks. They are started by a :: at the end of the preceding paragraph and delimited by indentation.
Representing an interactive session requires including the prompts and output along with the Python code. No special markup is required for interactive sessions. After the last line of input or output presented, there should not be an "unused" primary prompt; this is an example of what not to do:
>>> 1 + 1 2 >>>
Syntax highlighting is handled in a smart way:
There is a "highlighting language" for each source file. Per default, this is 'python' as the majority of files will have to highlight Python snippets.
Within Python highlighting mode, interactive sessions are recognized automatically and highlighted appropriately.
The highlighting language can be changed using the highlightlang directive, used as follows:
.. highlightlang:: c
This language is used until the next highlightlang directive is encountered.
The values normally used for the highlighting language are:
- python (the default)
- none (no highlighting)
If highlighting with the current language fails, the block is not highlighted in any way.
Longer displays of verbatim text may be included by storing the example text in an external file containing only plain text. The file may be included using the literalinclude directive.  For example, to include the Python source file :file:`example.py`, use:
.. literalinclude:: example.py
The file name is relative to the current file's path. Documentation-specific include files should be placed in the Doc/includes subdirectory.
As said before, Sphinx uses interpreted text roles to insert semantic markup in documents.
Names of local variables, such as function/method arguments, are an exception, they should be marked simply with *var*.
For all other roles, you have to write :rolename:`content`.
There are some additional facilities that make cross-referencing roles more versatile:
You may supply an explicit title and reference target, like in reST direct hyperlinks: :role:`title <target>` will refer to target, but the link text will be title.
If you prefix the content with !, no reference/hyperlink will be created.
For the Python object roles, if you prefix the content with ~, the link text will only be the last component of the target. For example, :meth:`~Queue.Queue.get` will refer to Queue.Queue.get but only display get as the link text.
In HTML output, the link's title attribute (that is e.g. shown as a tool-tip on mouse-hover) will always be the full target name.
The following roles refer to objects in modules and are possibly hyperlinked if a matching identifier is found:
The name enclosed in this markup can include a module name and/or a class name. For example, :func:`filter` could refer to a function named filter in the current module, or the built-in function of that name. In contrast, :func:`foo.filter` clearly refers to the filter function in the foo module.
Normally, names in these roles are searched first without any further qualification, then with the current module name prepended, then with the current module and class name (if any) prepended. If you prefix the name with a dot, this order is reversed. For example, in the documentation of the :mod:`codecs` module, :func:`open` always refers to the built-in function, while :func:`.open` refers to :func:`codecs.open`.
A similar heuristic is used to determine whether the name is an attribute of the currently documented class.
The following roles create cross-references to C-language constructs if they are defined in the API documentation:
The following role does possibly create a cross-reference, but does not refer to objects:
The following role creates a cross-reference to the term in the glossary:
The following roles don't do anything special except formatting the text in a different style:
The following roles generate external links:
Note that there are no special roles for including hyperlinks as you can use the standard reST markup for that purpose.
These directives create short paragraphs and can be used inside information units as well as normal text:
Since reST does not have facilities to interconnect several documents, or split documents into multiple output files, Sphinx uses a custom directive to add relations between the single files the documentation is made of, as well as tables of contents. The toctree directive is the central element.
Sphinx automatically creates index entries from all information units (like functions, classes or attributes) like discussed before.
However, there is also an explicit directive available, to make the index more comprehensive and enable index entries in documents where information is not mainly contained in information units, such as the language reference.
The directive is index and contains one or more index entries. Each entry consists of a type and a value, separated by a colon.
.. index:: single: execution; context module: __main__ module: sys triple: module; search; path
This directive contains five entries, which will be converted to entries in the generated index which link to the exact location of the index statement (or, in case of offline media, the corresponding page number).
The possible entry types are:
- Creates a single index entry. Can be made a subentry by separating the subentry text with a semicolon (this notation is also used below to describe what entries are created).
- pair: loop; statement is a shortcut that creates two index entries, namely loop; statement and statement; loop.
- Likewise, triple: module; search; path is a shortcut that creates three index entries, which are module; search path, search; path, module and path; module search.
- module, keyword, operator, object, exception, statement, builtin
- These all create two index entries. For example, module: hashlib creates the entries module; hashlib and hashlib; module.
For index directives containing only "single" entries, there is a shorthand notation:
.. index:: BNF, grammar, syntax, notation
This creates four index entries.
Grammar production displays
Special markup is available for displaying the productions of a formal grammar. The markup is simple and does not attempt to model all aspects of BNF (or any derived forms), but provides enough to allow context-free grammars to be displayed in a way that causes uses of a symbol to be rendered as hyperlinks to the definition of the symbol. There is this directive:
The following is an example taken from the Python Reference Manual:
.. productionlist:: try_stmt: try1_stmt | try2_stmt try1_stmt: "try" ":" `suite` : ("except" [`expression` ["," `target`]] ":" `suite`)+ : ["else" ":" `suite`] : ["finally" ":" `suite`] try2_stmt: "try" ":" `suite` : "finally" ":" `suite`