Epytext is a simple lightweight markup language that lets you add formatting and structue to docstrings. Epydoc uses that formatting and structure to produce nicely formatted API documentation. The following example (which has an unusually high ratio of documentaiton to code) illustrates some of the basic features of epytext:
def x_intercept(m, b): """ Return the x intercept of the line M{y=m*x+b}. The X{x intercept} of a line is the point at which it crosses the x axis (M{y=0}). This function can be used in conjuction with L{z_transform} to find an arbitrary function's zeros. @type m: number @param m: The slope of the line. @type b: number @param b: The y intercept of the line. The X{y intercept} of a line is the point at which it crosses the y axis (M{x=0}). @rtype: number @return: the x intercept of the line M{y=m*x+b}. """ return -b/m
You can compare this function definition with the API documentation generated by epydoc. Note that:
Epytext is intentionally very lightweight. If you wish to use a more expressive markup language, I recommend reStructuredText.
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.
o Basic Blocks are the basic unit of block structure.
o 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.
Block structure is encoded using indentation, blank lines, and a handful of special character sequences.
The following sections describe how to use each type of block structure.
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 |
|---|---|
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. |
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 |
|---|---|
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:
| 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.
|
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 |
|---|---|
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.
|
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 |
|---|---|
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. |
A section consists of a heading followed by one or more child blocks.
The following example illustrates how sections can be used:
| 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. |
Literal blocks are used to represent "preformatted" text. Everything within a literal block should be displayed exactly as it appears in plaintext. In particular:
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 |
|---|---|
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.
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 |
|---|---|
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. |
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 |
|---|---|
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.
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:
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 also escaping.
Epytext defines four types of inline markup that specify how text should be displayed:
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 |
|---|---|
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.
Without the capital letter, matching braces are not interpreted as markup: my_dict={1:2, 3:4}. |
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 |
|---|---|
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>} """ #[...] |
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>} """ #[...] |
In order to find the object that corresponds to a given name, epydoc checks the following locations, in order:
| 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. |
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.
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 |
|---|---|
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. |
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 |
|---|---|
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.
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:
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 also escaping.
Epytext defines four types of inline markup that specify how text should be displayed:
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 |
|---|---|
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.
Without the capital letter, matching braces are not interpreted as markup: my_dict={1:2, 3:4}. |
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 |
|---|---|
def example(): """ - U{www.python.org} - U{http://www.python.org} - U{The epydoc homepage& |