The Epytext Markup Language

1. Overview

Epytext is a lightweight markup language for Python docstrings. The epytext markup language is used by epydoc to parse docstrings and create structured API documentation. Epytext markup is broken up into the following categories:

Block Structure divides the docstring into nested blocks of text, such as paragraphs and lists.
- Basic Blocks are the basic unit of block structure.
- Hierarchical blocks represent the nesting structure of the docstring.
Inline Markup marks regions of text within a basic block with properties, such as italics and hyperlinks.

2. Block Structure

Block structure is encoded using indentation, blank lines, and a handful of special character sequences.

Indentation is used to encode the nesting structure of hierarchical blocks. The indentation of a line is defined as the number of leading spaces on that line; and the indentation of a block is typically the indentation of its first line.
Blank lines are used to separate blocks. A blank line is a line that only contains whitespace.
Special character sequences are used to mark the beginnings of some blocks. For example, "-" is used as a bullet for unordered list items, and ">>>" is used to mark doctest blocks.

The following sections describe how to use each type of block structure.

2.1. Paragraphs

A paragraph is the simplest type of basic block. It consists of one or more lines of text. Paragraphs must be left justified (i.e., every line must have the same indentation). The following example illustrates how paragraphs can be used:

Docstring Input Rendered Output

Docstring Input	Rendered Output
`def` `example`(): `""" This is a paragraph. Paragraphs can span multiple lines, and can contain I{inline markup}. This is another paragraph. Paragraphs are separated by blank lines. """` [...]	This is a paragraph. Paragraphs can span multiple lines, and contain inline markup. This is another paragraph. Paragraphs are separated from each other by blank lines.

def example():
    """
    This is a paragraph.  Paragraphs can
    span multiple lines, and can contain
    I{inline markup}.
    

    This is another paragraph.  Paragraphs
    are separated by blank lines.
    """
    [...]

This is a paragraph. Paragraphs can span multiple lines, and contain inline markup.

This is another paragraph. Paragraphs are separated from each other by blank lines.

2.2. Lists

Epytext supports both ordered and unordered lists. A list consists of one or more consecutive list items of the same type (ordered or unordered), with the same indentation. Each list item is marked by a bullet. The bullet for unordered list items is a single dash character ("-"). Bullets for ordered list items consist of a series of numbers followed by periods, such as "12." or "1.2.8.".

List items typically consist of a bullet followed by a space and a single paragraph. The paragraph may be indented more than the list item's bullet; often, the paragraph is intended two or three characters, so that its left margin lines up with the right side of the bullet. The following example illustrates a simple ordered list.

Docstring Input Rendered Output

Docstring Input	Rendered Output
`def` `example`(): `""" 1. This is an ordered list item. 2. This is a another ordered list item. 3. This is a third list item. Note that the paragraph may be indented more than the bullet. """` [...]	This is an ordered list item. This is another ordered list item. This is a third list item. Note that the paragraph may be indented more than the bullet.

def example():
    """
    1. This is an ordered list item.

    2. This is a another ordered list
    item.

    3. This is a third list item.  Note that
       the paragraph may be indented more
       than the bullet.
    """
    [...]

This is an ordered list item.
This is another ordered list item.
This is a third list item. Note that the paragraph may be indented more than the bullet.

List items can contain more than one paragraph; and they can also contain sublists, literal blocks, and doctest blocks. All of the blocks contained by a list item must all have equal indentation, and that indentation must be greater than or equal to the indentation of the list item's bullet. If the first contained block is a paragraph, it may appear on the same line as the bullet, separated from the bullet by one or more spaces, as shown in the previous example. All other block types must follow on separate lines.

Every list must be separated from surrounding blocks by indentation:

Docstring Input	Rendered Output
`def` `example`(): `""" This is a paragraph. 1. This is a list item. 2. This a second list item. - This is a sublist """` [...]	This is a paragraph. This is a list item. This is a second list item. This is a sublist.

Note that sublists must be separated from the blocks in their parent list item by indentation. In particular, the following docstring generates an error, since the sublist is not separated from the paragraph in its parent list item by indentation:

Docstring Input	Rendered Output
`def` `example`(): `""" 1. This is a list item. Its paragraph is indented 7 spaces. - This is a sublist. It is indented 7 spaces. """` [...]	L5: Error: Lists must be indented.

The following example illustrates how lists can be used:

Docstring Input Rendered Output

Docstring Input	Rendered Output
`def` `example`(): `""" This is a paragraph. 1. This is a list item. - This is a sublist. - The sublist contains two items. - The second item of the sublist has its own sublist. 2. This list item contains two paragraphs and a doctest block. >>> print 'This is a doctest block' This is a doctest block This is the second paragraph. """` [...]	This is a paragraph. This is a list item. This is a sublist. The sublist contains two items. The second item of the sublist has its own own sublist. This list item contains two paragraphs and a doctest block. `>>>` `print` `'This is a doctest block'` `This is a doctest block` This is the second paragraph.

def example():
    """
    This is a paragraph.
      1. This is a list item.
        - This is a sublist.
        - The sublist contains two
          items.
            - The second item of the 
              sublist has its own sublist.

      2. This list item contains two
         paragraphs and a doctest block.

         >>> print 'This is a doctest block'
         This is a doctest block

         This is the second paragraph.
    """
    [...]

This is a paragraph.

This is a list item.

This is a sublist.
The sublist contains two items.

The second item of the sublist has its own own sublist.

This list item contains two paragraphs and a doctest block.
```
>>> print 'This is a doctest block'
This is a doctest block
```
This is the second paragraph.

Epytext will treat any line that begins with a bullet as a list item. If you want to include bullet-like text in a paragraph, then you must either ensure that it is not at the beginning of the line, or use escaping to prevent epytext from treating it as markup:

Docstring Input Rendered Output

Docstring Input	Rendered Output
`def` `example`(): `""" This sentence ends with the number 1. Epytext can't tell if the "1." is a bullet or part of the paragraph, so it generates an error. """` [...]	L4: Error: Lists must be indented.
`def` `example`(): `""" This sentence ends with the number 1. This sentence ends with the number E{1}. """` [...]	This sentence ends with the number 1. This sentence ends with the number 1.

def example():
    """
    This sentence ends with the number
    1.  Epytext can't tell if the "1."
    is a bullet or part of the paragraph,
    so it generates an error.
    """
    [...]

L4: Error: Lists must be indented.

def example():
    """
    This sentence ends with the number 1.

    This sentence ends with the number
    E{1}.
    """
    [...]

This sentence ends with the number 1.

2.3. Sections

A section consists of a heading followed by one or more child blocks.

The heading is a single underlined line of text. Top-level section headings are underlined with the "=" character; subsection headings are underlined with the "-" character; and subsubsection headings are underlined with the "~" character. The length of the underline must exactly match the length of the heading.
The child blocks can be paragraphs, lists, literal blocks, doctest blocks, or sections. Each child must have equal indentation, and that indentation must be greater than or equal to the heading's indentation.

The following example illustrates how sections can be used:

Docstring Input Rendered Output

Docstring Input	Rendered Output
`def` `example`(): `""" This paragraph is not in any section. Section 1 ========= This is a paragraph in section 1. Section 1.1 ----------- This is a paragraph in section 1.1. Section 2 ========= This is a paragraph in section 2. """` [...]	Section 1 This is a paragraph in section 1. Section 1.1 This is a paragraph in section 1.1. Section 2 This is a paragraph in section 2.

def example():
    """
    This paragraph is not in any section.

    Section 1
    =========
      This is a paragraph in section 1.

      Section 1.1
      -----------
      This is a paragraph in section 1.1.

    Section 2
    =========
      This is a paragraph in section 2.
    """
    [...]

Section 1
This is a paragraph in section 1.

Section 1.1
This is a paragraph in section 1.1.

Section 2
This is a paragraph in section 2.

2.4. Literal Blocks

Literal blocks are used to represent "preformatted" text. Everything within a literal block should be displayed exactly as it appears in plaintext. In particular:

Spaces and newlines are preserved.
Text is shown in a monospaced font.
Inline markup is not detected.

Literal blocks are introduced by paragraphs ending in the special sequence "::". Literal blocks end at the first line whose indentation is equal to or less than that of the paragraph that introduces them. The following example shows how literal blocks can be used:

Docstring Input Rendered Output

Docstring Input	Rendered Output
`def` `example`(): `""" The following is a literal block:: Literal / / Block This is a paragraph following the literal block. """` [...]	The following is a literal block: Literal / / Block This is a paragraph following the literal block.

def example():
    """
    The following is a literal block::
    
        Literal /
               / Block

    This is a paragraph following the
    literal block.
    """
    [...]

The following is a literal block:

    Literal /
           / Block

This is a paragraph following the literal block.

Literal blocks are indented relative to the paragraphs that introduce them; for example, in the previous example, the word "Literal" is displayed with four leading spaces, not eight. Also, note that the double colon ("::") that introduces the literal block is rendered as a single colon.

2.5. Doctest Blocks

Doctest blocks contain examples consisting of Python expressions and their output. Doctest blocks can be used by the doctest module to test the documented object. Doctest blocks begin with the special sequence ">>>". Doctest blocks are delimited from surrounding blocks by blank lines. Doctest blocks may not contain blank lines. The following example shows how doctest blocks can be used:

Docstring Input Rendered Output

Docstring Input	Rendered Output
`def` `example`(): `""" The following is a doctest block: >>> print (1+3, ... 3+5) (4, 8) >>> 'a-b-c-d-e'.split('-') ['a', 'b', 'c', 'd', 'e'] This is a paragraph following the doctest block. """` [...]	The following is a doctest block: `>>>` `print` `(1+3,` `...` `3+5)` `(4, 8)` `>>>` `'a-b-c-d-e'.split('-')` `['a', 'b', 'c', 'd', 'e']` This is a paragraph following the doctest block.

def example():
    """
    The following is a doctest block:
    
        >>> print (1+3,
        ...        3+5)
        (4, 8)
        >>> 'a-b-c-d-e'.split('-')
        ['a', 'b', 'c', 'd', 'e']

    This is a paragraph following the
    doctest block.
    """
    [...]

The following is a doctest block:

>>> print (1+3,
...        3+5)
(4, 8)
>>> 'a-b-c-d-e'.split('-')
['a', 'b', 'c', 'd', 'e']

This is a paragraph following the doctest block.

2.6. Fields

Fields are used to describe specific properties of a documented object. For example, fields can be used to define the parameters and return value of a function; the instance variables of a class; and the author of a module. Each field is marked by a field tag, which consist of an at sign ("@") followed by a field name, optionally followed by a space and a field argument, followed by a colon (":"). For example, "@return:" and "@param x:" are field tags.

Fields can contain paragraphs, lists, literal blocks, and doctest blocks. All of the blocks contained by a field must all have equal indentation, and that indentation must be greater than or equal to the indentation of the field's tag. If the first contained block is a paragraph, it may appear on the same line as the field tag, separated from the field tag by one or more spaces. All other block types must follow on separate lines.

Fields must be placed at the end of the docstring, after the description of the object. Fields may be included in any order.

Fields do not need to be separated from other blocks by a blank line. Any line that begins with a field tag followed by a space or newline is considered a field.

The following example illustrates how fields can be used:

Docstring Input Rendered Output

Docstring Input	Rendered Output
`def` `example`(): `""" @param x: This is a description of the parameter x to a function. Note that the description is indented four spaces. @type x: This is a description of x's type. @return: This is a description of the function's return value. It contains two paragraphs. """` [...]	Parameters: `x` - This is a description of the parameter x to a function. Note that the description is indented four spaces. (type=This is a description of x's type.) Returns: This is a description of the function's return value. It contains two paragraphs.

def example():
    """
    @param x: This is a description of
        the parameter x to a function.
        Note that the description is
        indented four spaces.
    @type x: This is a description of
        x's type.
    @return: This is a description of
        the function's return value.

        It contains two paragraphs.
    """
    [...]

Parameters:: x - This is a description of the parameter x to a function. Note that the description is indented four spaces.
(type=This is a description of x's type.)

Returns:: This is a description of the function's return value.
It contains two paragraphs.

For a list of the fields that are supported by epydoc, see the epydoc fields page.

3. Inline Markup

Inline markup has the form "x{...}", where "x" is a single capital letter that specifies how the text between the braces should be rendered. Inline markup is recognized within paragraphs and section headings. It is not recognized within literal and doctest blocks. Inline markup can contain multiple words, and can span multiple lines. Inline markup may be nested.

A matching pair of curly braces is only interpreted as inline markup if the left brace is immediately preceeded by a capital letter. So in most cases, you can use curly braces in your text without any form of escaping. However, you do need to escape curly braces when:

You want to include a single (un-matched) curly brace.
You want to preceed a matched pair of curly braces with a capital letter.

Note that there is no valid Python expression where a pair of matched curly braces is immediately preceeded by a capital letter (except within string literals). In particular, you never need to escape braces when writing Python dictionaries. See section 3.5 for a discussion of escaping.

3.1. Basic Inline Markup

Epytext defines four types of inline markup that specify how text should be displayed:

I{...}: Italicized text.
B{...}: Bold-faced text.
C{...}: Source code or a Python identifier.
M{...}: A mathematical expression.

By default, source code is rendered in a fixed width font; and mathematical expressions are rendered in italics. But those defaults may be changed by modifying the CSS stylesheet. The following example illustrates how the four basic markup types can be used:

Docstring Input Rendered Output

Docstring Input	Rendered Output
`def` `example`(): `""" I{B{Inline markup} may be nested; and it may span} multiple lines. - I{Italicized text} - B{Bold-faced text} - C{Source code} - M{Math} Without the capital letter, matching braces are not interpreted as markup: C{my_dict={1:2, 3:4}}. """` [...]	Inline markup may be nested; and it may span multiple lines. Italicized text Bold-faced text `Source code` Math: mx+b* Without the capital letter, matching braces are not interpreted as markup: `my_dict={1:2, 3:4}`.

def example():
    """
    I{B{Inline markup} may be nested; and
    it may span} multiple lines.

      - I{Italicized text}
      - B{Bold-faced text}
      - C{Source code}
      - M{Math}

    Without the capital letter, matching
    braces are not interpreted as markup:
    C{my_dict={1:2, 3:4}}.
    """
    [...]

Inline markup may be nested; and it may span multiple lines.

Italicized text
Bold-faced text
Source code
Math: m*x+b

Without the capital letter, matching braces are not interpreted as markup: my_dict={1:2, 3:4}.

3.2. URLs

The inline markup construct "U{text<url>}" is used to create links to external URLs and URIs. "Text" is the text that should be displayed for the link, and "url" is the target of the link. If you wish to use the URL as the text for the link, you can simply write "U{url}". Whitespace within URL targets is ignored. In particular, URL targets may be split over multiple lines. The following example illustrates how URLs can be used:

Docstring Input Rendered Output

Docstring Input	Rendered Output
`def` `example`(): `""" - U{www.python.org} - U{http://www.python.org} - U{The epydoc homepage<http:// epydoc.sourceforge.net>} - U{The B{I{Python}} homepage <www.python.org>} - U{Edward Loper<mailto:edloper@ gradient.cis.upenn.edu>} """` [...]	www.python.org http://www.python.org The epydoc homepage The *Python* homepage Edward Loper

def example():
    """
    - U{www.python.org}
    - U{http://www.python.org}
    - U{The epydoc homepage<http://
      epydoc.sourceforge.net>}
    - U{The B{I{Python}} homepage
      <www.python.org>}
    - U{Edward Loper<mailto:edloper@
      gradient.cis.upenn.edu>}
    """
    [...]

3.3. Documentation Crossreference Links

The inline markup construct "L{text<object>}" is used to create links to the documentation for other Python objects. "Text" is the text that should be displayed for the link, and "object" is the name of the Python object that should be linked to. If you wish to use the name of the Python object as the text for the link, you can simply write "L{object}". Whitespace within object names is ignored. In particular, object names may be split over multiple lines. The following example illustrates how documentation crossreference links can be used:

Docstring Input	Rendered Output
`def` `example`(): `""" - L{x_transform} - L{search<re.search>} - L{The I{x-transform} function <x_transform>} """` [...]	`x_transform` `search` `The x-transform function`

In order to find the object that corresponds to a given name, epydoc checks the following locations, in order:

If the link is made from a class or method docstring, then epydoc checks for a method, instance variable, or class variable with the given name.
Next, epydoc looks for an object with the given name in the current module.
Epydoc then tries to import the given name as a module. If the current module is contained in a package, then epydoc will also try importing the given name from all packages containing the current module.
Finally, epydoc tries to divide the given name into a module name and an object name, and to import the object from the module. If the current module is contained in a package, then epydoc will also try importing the module name from all packages containing the current module.

If no object is found that corresponds with the given name, then epydoc issues a warning.

3.4. Indexed Terms

Epydoc automatically creates an index of term definitions for the API documentation. The inline markup construct "X{...}" is used to mark terms for inclusion in the index. The term itself will be italicized; and a link will be created from the index page to the location of the term in the text. The following example illustrates how index terms can be used:

Docstring Input Rendered Output

def example():
    """
    An X{index term} is a term that
    should be included in the index.
    """
    [...]

An index term is a term that should be included in the index.

Index
index term	example
x intercept	x_intercept
y intercept	x_intercept

3.5. Symbols

Symbols are used to insert special characters in your documentation. A symbol has the form "S{code}", where code is a symbol code that specifies what character should be produced. The following example illustrates how symbols can be used to generate special characters:

Docstring Input Rendered Output

Docstring Input	Rendered Output
`def` `example`(): `""" Symbols can be used in equations: - S{sum}S{alpha}/x S{<=} S{beta} S{<-} and S{larr} both give left arrows. Some other arrows are S{rarr}, S{uarr}, and S{darr}. """` [...]	Symbols can be used in equations: ∑α/x ≤ β ← and ← both give left arrows. Some other arrows are →, ↑, and ↓.

def example():
    """
    Symbols can be used in equations:
      - S{sum}S{alpha}/x S{<=} S{beta}

    S{<-} and S{larr} both give left
    arrows.  Some other arrows are
    S{rarr}, S{uarr}, and S{darr}.
    """
    [...]

Symbols can be used in equations:

∑α/x ≤ β

← and ← both give left arrows. Some other arrows are →, ↑, and ↓.

Although symbols can be quite useful, you should keep in mind that they can make it harder to read your docstring in plaintext. In general, symbols should be used sparingly. For a complete list of the symbols that are currently supported, see the reference documentation for epydoc.epytext.SYMBOLS.

3.6. Escaping

Escaping is used to write text that would otherwise be interpreted as epytext markup. Epytext was carefully constructed to minimize the need for this type of escaping; but sometimes, it is unavoidable. Escaped text has the form "E{code}", where code is an escape code that specifies what character should be produced. If the escape code is a single character (other than "{" or "}"), then that character is produced. For example, to begin a paragraph with a dash (which would normally signal a list item), write "E{-}". In addition, two special escape codes are defined: "E{lb}" produces a left curly brace ("{"); and "E{rb}" produces a right curly brace ("}"). The following example illustrates how escaping can be used:

Docstring Input Rendered Output

Docstring Input	Rendered Output
`def` `example`(): `""" This paragraph ends with two colons, but does not introduce a literal blockE{:}E{:} E{-} This is not a list item. Escapes can be used to write unmatched curly braces: E{rb}E{lb} """` [...]	This paragraph ends with two colons, but does not introduce a literal block:: - This is not a list item. Escapes can be used to write unmatched curly braces: }{

def example():
    """
    This paragraph ends with two
    colons, but does not introduce
    a literal blockE{:}E{:}

    E{-} This is not a list item.

    Escapes can be used to write
    unmatched curly braces:
    E{rb}E{lb}
    """
    [...]

This paragraph ends with two colons, but does not introduce a literal block::

- This is not a list item.

Escapes can be used to write unmatched curly braces: }{

3.7. Graphs

The inline markup construct "G{graphtype args...}" is used to insert automatically generated graphs. The following graphs generation constructions are currently defines:

Markup	Description
G{classtree `classes...`}	Display a class hierarchy for the given class or classes (including all superclasses & subclasses). If no class is specified, and the directive is used in a class's docstring, then that class's class hierarchy will be displayed.
G{packagetree `modules...`}	Display a package hierarchy for the given module or modules (including all subpackages and submodules). If no module is specified, and the directive is used in a module's docstring, then that module's package hierarchy will be displayed.
G{impotgraph `modules...`}	Display an import graph for the given module or modules. If no module is specified, and the directive is used in a module's docstring, then that module's import graph will be displayed.
G{callgraph `functions...`}	Display a call graph for the given function or functions. If no function is specified, and the directive is used in a function's docstring, then that function's call graph will be displayed.

4. Characters

4.1. Valid Characters

Valid characters for an epytext docstring are space ("\040"); newline ("\012"); and any letter, digit, or punctuation, as defined by the current locale. Control characters ("\000"-"\010" and "\013"-"\037") are not valid content characters. Tabs ("\011") are expanded to spaces, using the same algorithm used by the Python parser. Carridge-return/newline pairs ("\015\012") are converted to newlines.

4.2. Content Characters

Characters in a docstring that are not involved in markup are called content characters. Content characters are always displayed as-is. In particular, HTML codes are not passed through. For example, consider the following example:

Docstring Input	Rendered Output
`def` `example`(): `""" <B>test</B> """` [...]	<B>test</B>

The docstring is rendered as "<B>test</B>", and not as the word "test" in bold face.

4.3. Spaces and Newlines

In general, spaces and newlines within docstrings are treated as soft spaces. In other words, sequences of spaces and newlines (that do not contain a blank line) are rendered as a single space, and words may wrapped at spaces. However, within literal blocks and doctest blocks, spaces and newlines are preserved, and no word-wrapping occurs; and within URL targets and documentation link targets, whitespace is ignored.

5. Warnings and Errors

If epydoc encounters an error while processing a docstring, it issues a warning message that describes the error, and attempts to continue generating documentation. Errors related to epytext are divided into three categories:

Epytext Warnings are caused by epytext docstrings that contain questionable or suspicious markup. Epytext warnings do not prevent the docstring in question from being parsed.
Field Warnings are caused by epytext docstrings containing invalid fields. The contents of the invalid field are generally ignored.
Epytext Errors are caused by epytext docstrings that contain invalid markup. Whenever an epytext error is detected, the docstring in question is treated as a plaintext docstring.

The following sections list and describe the warning messages that epydoc can generate. They are intended as a reference resource, which you can search for more information and possible causes if you encounter an error and do not understand it. These descriptions are also available in the epydoc(1) man page.

5.1. Epytext Warnings

Possible mal-formatted field item.
Epytext detected a line that looks like a field item, but is not correctly formatted. This typically occurs when the trailing colon (":") is not included in the field tag.
Possible heading typo.
Epytext detected a pair of lines that looks like a heading, but the number of underline characters does not match the number of characters in the heading. The number of characters in these two lines must match exactly for them to be considered a heading.

5.2. Field Warnings

@param for unknown parameter param.
A @param field was used to specify the type for a parameter that is not included in the function's signature. This is typically caused by a typo in the parameter name.
tag did not expect an argument.
The field tag tag was used with an argument, but it does not take one.
tag expected an argument.
The field tag tag was used without an argument, but it requires one.
@type for unknown parameter param.
A @type field was used to specify the type for a parameter that is not included in the function's signature. This is typically caused by a typo in the parameter name.
@type for unknown variable var.
A @type field was used to specify the type for a variable, but no other information is known about the variable. This is typically caused by a typo in the variable name.
Unknown field tag tag.
A docstring contains a field with the unknown tag tag.
Redefinition of field.
Multiple field tags define the value of field in the same docstring, but field can only take a single value.

5.3. Epytext Errors

Bad link target.
The target specified for an inline link contruction (L{...}) is not well-formed. Link targets must be valid python identifiers.
Bad uri target.
The target specified for an inline uri contruction (U{...}) is not well-formed. This typically occurs if inline markup is nested inside the URI target.
Fields must be at the top level.
The list of fields (@param, etc.) is contained by some other block structure (such as a list or a section).
Fields must be the final elements in an epytext string.
The list of fields (@param, etc.) is not at the end of a docstring.
Headings must occur at top level.
The heading is contianed in some other block structure (such as a list).
Improper doctest block indentation.
The doctest block dedents past the indentation of its initial prompt line.
Improper heading indentation.
The heading for a section is not left-aligned with the paragraphs in the section that contains it.
Improper paragraph indentation.
The paragraphs within a block are not left-aligned. This error is often generated when plaintext docstrings are parsed using epytext.
Invalid escape.
An unknown escape sequence was used with the inline escape construction (E{...}).
Lists must be indented.
An unindented line immediately following a paragraph starts with a list bullet. Epydoc is not sure whether you meant to start a new list item, or meant for a paragraph to include a word that looks like a bullet. If you intended the former, then indent the list. If you intended the latter, then change the word-wrapping of the paragraph, or escape the first character of the word that looks like a bullet.
Unbalanced '{'.
The docstring contains unbalanced braces. Epytext requires that all braces must be balanced. To include a single unbalanced brace, use the escape sequences E{lb} (left brace) and E{rb} (right brace).
Unbalanced '}'.
The docstring contains unbalanced braces. Epytext requires that all braces must be balanced. To include a single unbalanced brace, use the escape sequences E{lb} (left brace) and E{rb} (right brace).
Unknown inline markup tag.
An unknown tag was used with the inline markup construction (x{...}).
Wrong underline character for heading.
The underline character used for this section heading does not indicate an appopriate section level. The "=" character should be used to underline sections; "-" for subsections; and "~" for subsubsections.