2.1.1   Command Line Usage (Abbreviated)

epydoc [--html|--pdf] [-o DIR] [--parse-only|--introspect-only] [-v|-q]
       [--name NAME] [--url URL] [--docformat NAME] [--graph GRAPHTYPE]
       [--inheritance STYLE] [--config FILE] OBJECTS...

OBJECTS...

A list of the Python objects that should be documented. Objects can be specified using dotted names (such as os.path), module filenames (such as epydoc/epytext.py), or package directory names (such as epydoc/). Packages are expanded to include all sub-modules and sub-packages.

The complete list of command line options is available in the Command Line Usage section.

2.1.2   Examples

The following command will generate HTML documentation for the sys module, and write it to the directory sys_docs:

[epydoc]$ epydoc --html sys -o sys_docs

The following commands are used to produce the API documentation for epydoc itself. The first command writes html output to the directory html/api, using epydoc as the project name and http://epydoc.sourcforge.net as the project URL. The white CSS style is used; inheritance is displayed using the listed style; and all graphs are included in the output. The second command writes pdf output to the file api.pdf in the directory latex/api, using Epydoc as the project name.

[epydoc]$ epydoc -v -o html/api --name epydoc --css white \
                 --url http://epydoc.sourceforge.net \
                 --inheritance listed --graph all src/epydoc
[epydoc]$ epydoc -v -o latex/api --pdf --name "Epydoc" src/epydoc

2.1.3   Configuration Files

Configuration files, specified using the --config option, may be used to specify both the list of objects to document, and the options that should be used to document them. Configuration files are read using the standard ConfigParser module. The following is a simple example of a configuration file.

[epydoc] # Epydoc section marker (required by ConfigParser)

# Information about the project.
name: My Cool Project
url: http://cool.project/

# The list of modules to document.  Modules can be named using
# dotted names, module filenames, or package directory names.
# This option may be repeated.
modules: sys, os.path, re
modules: my/project/driver.py

# Write html output to the directory "apidocs"
output: html
target: apidocs/

# Include all automatically generated graphs.  These graphs are
# generated using Graphviz dot.
graph: all
dotpath: /usr/local/bin/dot

A more complete example, including all of the supported options, is also available.

4.3.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:

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.
    """
    *[...]*

4.3.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.

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.
    """
    *[...]*

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:

def example():
    """
    This is a paragraph.
      1. This is a list item.
      2. This 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:

def example():
    """
    1. This is a list item.  Its
    paragraph is indented 7 spaces.
    - This is a sublist.  It is
      indented 7 spaces.
    """
    #[...]

The following example illustrates how lists can be used:

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.
    """
    #[...]

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:

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.
    """
    #[...]

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

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

4.3.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:

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.
    """
    #[...]

4.3.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:

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

        Literal /
               / Block

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

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.

4.3.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:

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.
    """
    #[...]

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

4.3.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:

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.
    """
    #[...]

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

4.4.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:

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}}.
    """
    #[...]

4.4.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:

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

4.4.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:

def example():
    """
    - L{x_transform}
    - L{search<re.search>}
    - L{The I{x-transform} function
    <x_transform>}
    """
    #[...]

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

1. 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.
2. Next, epydoc looks for an object with the given name in the current module.
3. 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.
4. Epydoc then 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.
5. Finally, epydoc looks for a class name in any module with the given name. This is only returned if there is a single class with such name.

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

4.4.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:

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

4.4.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:

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}.
    """
    #[...]

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 epytext.SYMBOLS.

4.4.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:

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}
    """
    #[...]

4.4.7   Graphs

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

4.5.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.5.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:

def example():
    """
    <B>test</B>
    """
    #[...]

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

4.5.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.2.1   Functions and Methods parameters

@param p: ...

A description of the parameter p for a function or method.

@type p: ...

The expected type for the parameter p.

@return: ...

The return value for a function or method.

@rtype: ...

The type of the return value for a function or method.

@keyword p: ...

A description of the keyword parameter p.

@raise e: ...

A description of the circumstances under which a function or method raises exception e.

These tags can be used to specify attributes of parameters and return value of function and methods. These tags are usually put in the the docstring of the function to be documented.

@param fields should be used to document any explicit parameter (including the keyword parameter). @keyword fields should only be used for non-explicit keyword parameters:

def plant(seed, *tools, **options):
    """
    @param seed: The seed that should be planted.
    @param tools: Tools that should be used to plant the seed.
    @param options: Any extra options for the planting.

    @keyword dig_deep: Plant the seed deep under ground.
    @keyword soak: Soak the seed before planting it.
    """
    #[...]

Since the @type field allows for arbitrary text, it does not automatically create a crossreference link to the specified type, and is not written in fixed-width font by default. If you want to create a crossreference link to the type, or to write the type in a fixed-width font, then you must use inline markup:

def ponder(person, time):
    """
    @param person: Who should think.
    @type person: L{Person} or L{Animal}
    @param time: How long they should think.
    @type time: C{int} or C{float}
    """
    #[...]

5.2.2   Variables parameters

@ivar v: ...

A description of the class instance variable v.

@cvar v: ...

A description of the static class variable v.

@var v: ...

A description of the module variable v.

@type v: ...

The type of the variable v.

These tags are usually put in a module or class docstring. If the sources can be parsed by Epydoc it is also possible to document the variable in their own docstrings: see variable docstrings

Epydoc considers class variables the ones defined directly defined in the class body. A common Python idiom is to create instance variables settings their default value in the class instead of the constructor (hopefully if the default is immutable...).

If you want to force Epydoc to classify as instance variable one whose default value is set at class level, you can describe it using the tag @ivar in the context of a variable docstring:

class B:
    y = 42
    """@ivar: This is an instance variable."""

5.2.3   Properties parameters

@type: ...

The type of the property.

The @type tag can be attached toa property docstring to specify its type.

5.2.4   Grouping and Sorting

@group g: c1,...,cn

Organizes a set of related children of a module or class into a group. g is the name of the group; and c1,...,cn are the names of the children in the group. To define multiple groups, use multiple group fields.

@sort: c1,...,cn

Specifies the sort order for the children of a module or class. c1,...,cn are the names of the children, in the order in which they should appear. Any children that are not included in this list will appear after the children from this list, in alphabetical order.

These tags can be used to present groups of related items in a logical way. They apply to modules and classes docstrings.

For the @group and @sort tags, asterisks (*) can be used to specify multiple children at once. An asterisk in a child name will match any substring:

class widget(size, weight, age):
    """
    @group Tools: zip, zap, *_tool
    @group Accessors: get_*
    @sort: get_*, set_*, unpack_*, cut
    """
    #[...]

#{ Database access functions

def read(id):
    #[...]

def store(item):
    #[...]

def delete(id):
    #[...]

# groups can't be nested, so a closing marker is not required here.

#{ Web publish functions

def get(request):
    #[...]

def post(request):
    #[...]

#}

5.2.5   Notes and Warnings

@note: ...

A note about an object. Multiple note fields may be used to list separate notes.

@attention: ...

An important note about an object. Multiple attention fields may be used to list separate notes.

@bug: ...

A description of a bug in an object. Multiple bug fields may be used to report separate bugs.

Note

If any @bug field is used, the HTML writer will generate a the page bug-index.html, containing links to all the items tagged with the field.

@warning: ...

A warning about an object. Multiple warning fields may be used to report separate warnings.

5.2.6   Status

@version: ...

The current version of an object.

@todo [ver]: ...

A planned change to an object. If the optional argument ver is given, then it specifies the version for which the change will be made. Multiple todo fields may be used if multiple changes are planned.

Note

If any @todo field is used, the HTML writer will generate a the page todo-index.html, containing links to all the items tagged with the field.

@deprecated: ...

Indicates that an object is deprecated. The body of the field describe the reason why the object is deprecated.

@since: ...

The date or version when an object was first introduced.

@status: ...

The current status of an object.

@change: ...

A change log entry for this object.

@permission: ...

The object access permission, for systems such Zope/Plone supporting this concept. It may be used more than once to specify multiple permissions.

5.2.7   Formal Conditions

@requires: ...

A requirement for using an object. Multiple requires fields may be used if an object has multiple requirements.

@precondition: ...

A condition that must be true before an object is used. Multiple precondition fields may be used if an object has multiple preconditions.

@postcondition: ...

A condition that is guaranteed to be true after an object is used. Multiple postcondition fields may be used if an object has multiple postconditions.

@invariant: ...

A condition which should always be true for an object. Multiple invariant fields may be used if an object has multiple invariants.

5.2.8   Bibliographic Information

@author: ...

The author(s) of an object. Multiple author fields may be used if an object has multiple authors.

@organization: ...

The organization that created or maintains an object.

@copyright: ...

The copyright information for an object.

@license: ...

The licensing information for an object.

@contact: ...

Contact information for the author or maintainer of a module, class, function, or method. Multiple contact fields may be used if an object has multiple contacts.

5.2.9   Other fields

@summary: ...

A summary description for an object. This description overrides the default summary (which is constructed from the first sentence of the object's description).

@see: ...

A description of a related topic. see fields typically use documentation crossreference links or external hyperlinks that link to the related topic.

6.1.1   Default role

Epydoc replaces the Docutils' default interpreted text role with the creation of documentation crossreference links. If you want to create a crossreference link to the somemod.Example class, you can put backquotes around your test, typing:

`somemod.Example`

6.1.2   Consolidated Fields

In addition to the standard set of fields, the reStructruedText parser also supports consolidated fields, which combine the documentation for several objects into a single field. For example, a single :Parameters: field is often used to describe all of the parameters for a function or method:

def fox_speed(size, weight, age):
    """
    Return the maximum speed for a fox.

    :Parameters:
    - `size`: The size of the fox (in meters)