Persisting the Python session across IPython directive blocks

The state from previous sessions is stored, and standard error is trapped. At doc build time, ipython's output and std err will be inserted, and prompts will be renumbered. So the prompt below should be renumbered in the rendered docs, and pick up where the block above left off.

Adding documentation tests to your IPython directive

The embedded interpreter supports some limited markup. For example, you can put comments in your ipython sessions, which are reported verbatim. There are some handy "pseudo-decorators" that let you doctest the output. The inputs are fed to an embedded ipython session and the outputs from the ipython session are inserted into your doc. If the output in your doc and in the ipython session don't match on a doctest assertion, an error will occur.

For more information on @doctest decorator, please refer to the end of this page in Pseudo-Decorators section.

Multi-line input

Multi-line input is supported.

Testing directive outputs

The IPython Sphinx Directive makes it possible to test the outputs that you provide with your code. To do this, decorate the contents in your directive block with one of the following:

• list directives here

If an IPython doctest decorator is found, it will take these steps when your documentation is built:

1. Run the input lines in your IPython directive block against the current Python kernel (remember that the session persists across IPython directive blocks);

2. Compare the output of this with the output text that you've put in the IPython directive block 9what comes after Out[NN]);

3. If there is a difference, the directive will raise an error and your documentation build will fial.

You can do doctesting on multi-line output as well. Just be careful when using non-deterministic inputs like random numbers in the ipython directive, because your inputs are run through a live interpreter, so if you are doctesting random output you will get an error. Here we "seed" the random number generator for deterministic output, and we suppress the seed line so it doesn't show up in the rendered output

For more information on @supress and @doctest decorators, please refer to the end of this file in Pseudo-Decorators section.

Another demonstration of multi-line input and output

Most of the "pseudo-decorators" can be used an options to ipython mode. For example, to setup matplotlib pylab but suppress the output, you can do. When using the matplotlib use directive, it should occur before any import of pylab. This will not show up in the rendered docs, but the commands will be executed in the embedded interpreter and subsequent line numbers will be incremented to reflect the inputs:

.. ipython::
   :suppress:

   In [144]: from matplotlib.pylab import *

   In [145]: ion()

Likewise, you can set :doctest: or :verbatim: to apply these settings to the entire block. For example,

You can create one or more pyplot plots and insert them with the @savefig decorator.

For more information on @savefig decorator, please refer to the end of this page in Pseudo-Decorators section.

In a subsequent session, we can update the current figure with some text, and then resave

You can also have function definitions included in the source.

Then call it from a subsequent section.

.. ipython:: python

   foo = 'bar'
   print(foo)
   foo = 2
   foo**2

Handling Comments

Comments are handled and state is preserved

If you don't see the next code block then the options work.

Splitting Python statements across lines

Multi-line input is handled.

Functions definitions are correctly parsed

And persist across sessions

Pretty much anything you can do with the ipython code, you can do with with a simple python script. Obviously, though it doesn't make sense to use the doctest option.

Pseudo-Decorators

Here are the supported decorators, and any optional arguments they take. Some of the decorators can be used as options to the entire block (eg verbatim and suppress), and some only apply to the line just below them (eg savefig).

@suppress

execute the ipython input block, but suppress the input and output block from the rendered output. Also, can be applied to the entire .. ipython block as a directive option with :suppress:.

@verbatim

insert the input and output block in verbatim, but auto-increment the line numbers. Internally, the interpreter will be fed an empty string, so it is a no-op that keeps line numbering consistent. Also, can be applied to the entire .. ipython block as a directive option with :verbatim:.

@savefig OUTFILE [IMAGE_OPTIONS]

save the figure to the static directory and insert it into the document, possibly binding it into a minipage and/or putting code/figure label/references to associate the code and the figure. Takes args to pass to the image directive (scale, width, etc can be kwargs); see image options for details.

@doctest

Compare the pasted in output in the ipython block with the output generated at doc build time, and raise errors if they don't match. Also, can be applied to the entire .. ipython block as a directive option with :doctest:.

Configuration Options

ipython_savefig_dir

The directory in which to save the figures. This is relative to the Sphinx source directory. The default is html_static_path.

ipython_rgxin

The compiled regular expression to denote the start of IPython input lines. The default is re.compile('In [(d+)]:s?(.*)s*'). You shouldn't need to change this.

ipython_rgxout

The compiled regular expression to denote the start of IPython output lines. The default is re.compile('Out[(d+)]:s?(.*)s*'). You shouldn't need to change this.

ipython_promptin

The string to represent the IPython input prompt in the generated ReST. The default is 'In [%d]:'. This expects that the line numbers are used in the prompt.

ipython_promptout

The string to represent the IPython prompt in the generated ReST. The default is 'Out [%d]:'. This expects that the line numbers are used in the prompt.

Automatically generated documentation