Writing documentation#

Getting started#

General file structure#

All documentation is built from the doc/. The doc/ directory contains configuration files for Sphinx and reStructuredText (ReST; .rst) files that are rendered to documentation pages.

Documentation is created in three ways. First, API documentation (doc/api) is created by Sphinx from the docstrings of the classes in the Matplotlib library. Except for doc/api/api_changes/, .rst files in doc/api are created when the documentation is built. See Writing docstrings below.

Second, the contents of doc/plot_types, doc/gallery and doc/tutorials are generated by the Sphinx Gallery from python files in plot_types/, examples/ and tutorials/. These sources consist of python scripts that have ReST documentation built into their comments. See Writing examples and tutorials below.

Third, Matplotlib has narrative docs written in ReST in subdirectories of doc/users/. If you would like to add new documentation that is suited to an .rst file rather than a gallery or tutorial example, choose an appropriate subdirectory to put it in, and add the file to the table of contents of index.rst of the subdirectory. See Writing ReST pages below.


Don't directly edit the .rst files in doc/plot_types, doc/gallery, doc/tutorials, and doc/api (excepting doc/api/api_changes/). Sphinx regenerates files in these directories when building documentation.

Setting up the doc build#

The documentation for Matplotlib is generated from reStructuredText (ReST) using the Sphinx documentation generation tool.

To build the documentation you will need to set up Matplotlib for development. Note in particular the additional dependencies required to build the documentation.

Building the docs#

The documentation sources are found in the doc/ directory in the trunk. The configuration file for Sphinx is doc/conf.py. It controls which directories Sphinx parses, how the docs are built, and how the extensions are used. To build the documentation in html format, cd into doc/ and run:

make html

Other useful invocations include

# Delete built files.  May help if you get errors about missing paths or
# broken links.
make clean

# Build pdf docs.
make latexpdf

The SPHINXOPTS variable is set to -W --keep-going by default to build the complete docs but exit with exit status 1 if there are warnings. To unset it, use

make SPHINXOPTS= html

You can use the O variable to set additional options:

  • make O=-j4 html runs a parallel build with 4 processes.

  • make O=-Dplot_formats=png:100 html saves figures in low resolution.

  • make O=-Dplot_gallery=0 html skips the gallery build.

Multiple options can be combined, e.g. make O='-j4 -Dplot_gallery=0' html.

On Windows, set the options as environment variables, e.g.:

set SPHINXOPTS= & set O=-j4 -Dplot_gallery=0 & make html

Showing locally built docs#

The built docs are available in the folder build/html. A shortcut for opening them in your default browser is:

make show

Writing ReST pages#

Most documentation is either in the docstrings of individual classes and methods, in explicit .rst files, or in examples and tutorials. All of these use the ReST syntax and are processed by Sphinx.

The Sphinx reStructuredText Primer is a good introduction into using ReST. More complete information is available in the reStructuredText reference documentation.

This section contains additional information and conventions how ReST is used in the Matplotlib documentation.

Formatting and style conventions#

It is useful to strive for consistency in the Matplotlib documentation. Here are some formatting and style conventions that are used.

Section formatting#

For everything but top-level chapters, use Upper lower for section titles, e.g., Possible hangups rather than Possible Hangups

We aim to follow the recommendations from the Python documentation and the Sphinx reStructuredText documentation for section markup characters, i.e.:

  • # with overline, for parts. This is reserved for the main title in index.rst. All other pages should start with "chapter" or lower.

  • * with overline, for chapters

  • =, for sections

  • -, for subsections

  • ^, for subsubsections

  • ", for paragraphs

This may not yet be applied consistently in existing docs.

Function arguments#

Function arguments and keywords within docstrings should be referred to using the *emphasis* role. This will keep Matplotlib's documentation consistent with Python's documentation:

Here is a description of *argument*

Do not use the `default role`:

Do not describe `argument` like this.  As per the next section,
this syntax will (unsuccessfully) attempt to resolve the argument as a
link to a class or method in the library.

nor the ``literal`` role:

Do not describe ``argument`` like this.

Referring to other documents and sections#

Sphinx allows internal references between documents.

Documents can be linked with the :doc: directive:

See the :doc:`/users/installing/index`

See the tutorial :doc:`/tutorials/introductory/quick_start`

See the example :doc:`/gallery/lines_bars_and_markers/simple_plot`

will render as:

See the Installation

See the tutorial Quick start guide

See the example Simple Plot

Sections can also be given reference names. For instance from the Installation link:

.. _clean-install:

How to completely remove Matplotlib

Occasionally, problems with Matplotlib can be solved with a clean...

and refer to it using the standard reference syntax:

See :ref:`clean-install`

will give the following link: How to completely remove Matplotlib

To maximize internal consistency in section labeling and references, use hyphen separated, descriptive labels for section references. Keep in mind that contents may be reorganized later, so avoid top level names in references like user or devel or faq unless necessary, because for example the FAQ "what is a backend?" could later become part of the users guide, so the label:

.. _what-is-a-backend:

is better than:

.. _faq-backend:

In addition, since underscores are widely used by Sphinx itself, use hyphens to separate words.

Referring to other code#

To link to other methods, classes, or modules in Matplotlib you can use back ticks, for example:


generates a link like this: matplotlib.collections.LineCollection.

Note: We use the sphinx setting default_role = 'obj' so that you don't have to use qualifiers like :class:, :func:, :meth: and the likes.

Often, you don't want to show the full package and module name. As long as the target is unambiguous you can simply leave them out:


and the link still works: LineCollection.

If there are multiple code elements with the same name (e.g. plot() is a method in multiple classes), you'll have to extend the definition:

`.pyplot.plot` or `.Axes.plot`

These will show up as pyplot.plot or Axes.plot. To still show only the last segment you can add a tilde as prefix:

`~.pyplot.plot` or `~.Axes.plot`

will render as plot or plot.

Other packages can also be linked via intersphinx:


will return this link: numpy.mean. This works for Python, Numpy, Scipy, and Pandas (full list is in doc/conf.py). If external linking fails, you can check the full list of referenceable objects with the following commands:

python -m sphinx.ext.intersphinx 'https://docs.python.org/3/objects.inv'
python -m sphinx.ext.intersphinx 'https://numpy.org/doc/stable/objects.inv'
python -m sphinx.ext.intersphinx 'https://docs.scipy.org/doc/scipy/objects.inv'
python -m sphinx.ext.intersphinx 'https://pandas.pydata.org/pandas-docs/stable/objects.inv'

Including figures and files#

Image files can directly included in pages with the image:: directive. e.g., tutorials/intermediate/constrainedlayout_guide.py displays a couple of static images:

# .. image:: /_static/constrained_layout_1b.png
#    :align: center

Files can be included verbatim. For instance the LICENSE file is included at License agreement using

.. literalinclude:: ../../LICENSE/LICENSE

The examples directory is copied to doc/gallery by sphinx-gallery, so plots from the examples directory can be included using

.. plot:: gallery/lines_bars_and_markers/simple_plot.py

Note that the python script that generates the plot is referred to, rather than any plot that is created. Sphinx-gallery will provide the correct reference when the documentation is built.

Writing docstrings#

Most of the API documentation is written in docstrings. These are comment blocks in source code that explain how the code works.


Some parts of the documentation do not yet conform to the current documentation style. If in doubt, follow the rules given here and not what you may see in the source code. Pull requests updating docstrings to the current style are very welcome.

All new or edited docstrings should conform to the numpydoc docstring guide. Much of the ReST syntax discussed above (Writing ReST pages) can be used for links and references. These docstrings eventually populate the doc/api directory and form the reference documentation for the library.

Example docstring#

An example docstring looks like:

def hlines(self, y, xmin, xmax, colors=None, linestyles='solid',
           label='', **kwargs):
    Plot horizontal lines at each *y* from *xmin* to *xmax*.

    y : float or array-like
        y-indexes where to plot the lines.

    xmin, xmax : float or array-like
        Respective beginning and end of each line. If scalars are
        provided, all lines will have the same length.

    colors : list of colors, default: :rc:`lines.color`

    linestyles : {'solid', 'dashed', 'dashdot', 'dotted'}, optional

    label : str, default: ''


    Other Parameters
    data : indexable object, optional
    **kwargs :  `~matplotlib.collections.LineCollection` properties.

    See Also
    vlines : vertical lines
    axhline : horizontal line across the Axes

See the hlines documentation for how this renders.

The Sphinx website also contains plenty of documentation concerning ReST markup and working with Sphinx in general.

Formatting conventions#

The basic docstring conventions are covered in the numpydoc docstring guide and the Sphinx documentation. Some Matplotlib-specific formatting conventions to keep in mind:

Quote positions#

The quotes for single line docstrings are on the same line (pydocstyle D200):

def get_linewidth(self):
    """Return the line width in points."""

The quotes for multi-line docstrings are on separate lines (pydocstyle D213):

def set_linestyle(self, ls):
Set the linestyle of the line.


Function arguments#

Function arguments and keywords within docstrings should be referred to using the *emphasis* role. This will keep Matplotlib's documentation consistent with Python's documentation:

If *linestyles* is *None*, the default is 'solid'.

Do not use the `default role` or the ``literal`` role:

Neither `argument` nor ``argument`` should be used.

Quotes for strings#

Matplotlib does not have a convention whether to use single-quotes or double-quotes. There is a mixture of both in the current code.

Use simple single or double quotes when giving string values, e.g.

If 'tight', try to figure out the tight bbox of the figure.

No ``'extra'`` literal quotes.

The use of extra literal quotes around the text is discouraged. While they slightly improve the rendered docs, they are cumbersome to type and difficult to read in plain-text docs.

Parameter type descriptions#

The main goal for parameter type descriptions is to be readable and understandable by humans. If the possible types are too complex use a simplification for the type description and explain the type more precisely in the text.

Generally, the numpydoc docstring guide conventions apply. The following rules expand on them where the numpydoc conventions are not specific.

Use float for a type that can be any number.

Use (float, float) to describe a 2D position. The parentheses should be included to make the tuple-ness more obvious.

Use array-like for homogeneous numeric sequences, which could typically be a numpy.array. Dimensionality may be specified using 2D, 3D, n-dimensional. If you need to have variables denoting the sizes of the dimensions, use capital letters in brackets ((M, N) array-like). When referring to them in the text they are easier read and no special formatting is needed. Use array instead of array-like for return types if the returned object is indeed a numpy array.

float is the implicit default dtype for array-likes. For other dtypes use array-like of int.

Some possible uses:

2D array-like
(N,) array-like
(M, N) array-like
(M, N, 3) array-like
array-like of int

Non-numeric homogeneous sequences are described as lists, e.g.:

list of str
list of `.Artist`

Referencing types#

Generally, the rules from referring-to-other-code apply. More specifically:

Use full references `~matplotlib.colors.Normalize` with an abbreviation tilde in parameter types. While the full name helps the reader of plain text docstrings, the HTML does not need to show the full name as it links to it. Hence, the ~-shortening keeps it more readable.

Use abbreviated links `.Normalize` in the text.

norm : `~matplotlib.colors.Normalize`, optional
     A `.Normalize` instance is used to scale luminance data to 0, 1.

Default values#

As opposed to the numpydoc guide, parameters need not be marked as optional if they have a simple default:

  • use {name} : {type}, default: {val} when possible.

  • use {name} : {type}, optional and describe the default in the text if it cannot be explained sufficiently in the recommended manner.

The default value should provide semantic information targeted at a human reader. In simple cases, it restates the value in the function signature. If applicable, units should be added.

    interval : int, default: 1000ms
    interval : int, default: 1000

If None is only used as a sentinel value for "parameter not specified", do not document it as the default. Depending on the context, give the actual default, or mark the parameter as optional if not specifying has no particular effect.

    dpi : float, default: :rc:`figure.dpi`
    dpi : float, default: None

    textprops : dict, optional
        Dictionary of keyword parameters to be passed to the
        `~matplotlib.text.Text` instance contained inside TextArea.
    textprops : dict, default: None
        Dictionary of keyword parameters to be passed to the
        `~matplotlib.text.Text` instance contained inside TextArea.

See also sections#

Sphinx automatically links code elements in the definition blocks of See also sections. No need to use backticks there:

See Also
vlines : vertical lines
axhline : horizontal line across the Axes

Wrapping parameter lists#

Long parameter lists should be wrapped using a \ for continuation and starting on the new line without any indent (no indent because pydoc will parse the docstring and strip the line continuation so that indent would result in a lot of whitespace within the line):

def add_axes(self, *args, **kwargs):

    projection : {'aitoff', 'hammer', 'lambert', 'mollweide', 'polar', \
'rectilinear'}, optional
        The projection type of the axes.


Alternatively, you can describe the valid parameter values in a dedicated section of the docstring.


rcParams can be referenced with the custom :rc: role: :rc:`foo` yields rcParams["foo"] = 'default', which is a link to the matplotlibrc file description.

Setters and getters#

Artist properties are implemented using setter and getter methods (because Matplotlib predates the Python property decorator). By convention, these setters and getters are named set_PROPERTYNAME and get_PROPERTYNAME; the list of properties thusly defined on an artist and their values can be listed by the setp and getp functions.

The Parameters block of property setter methods is parsed to document the accepted values, e.g. the docstring of Line2D.set_linestyle starts with

def set_linestyle(self, ls):
    Set the linestyle of the line.

    ls : {'-', '--', '-.', ':', '', (offset, on-off-seq), ...}

which results in the following line in the output of plt.setp(line) or plt.setp(line, "linestyle"):

linestyle or ls: {'-', '--', '-.', ':', '', (offset, on-off-seq), ...}

In some rare cases (mostly, setters which accept both a single tuple and an unpacked tuple), the accepted values cannot be documented in such a fashion; in that case, they can be documented as an .. ACCEPTS: block, e.g. for axes.Axes.set_xlim:

def set_xlim(self, ...):
    Set the x-axis view limits.

    left : float, optional
        The left xlim in data coordinates. Passing *None* leaves the
        limit unchanged.

        The left and right xlims may also be passed as the tuple
        (*left*, *right*) as the first positional argument (or as
        the *left* keyword argument).

        .. ACCEPTS: (bottom: float, top: float)

    right : float, optional

Note that the leading .. makes the .. ACCEPTS: block a reST comment, hiding it from the rendered docs.

Keyword arguments#


The information in this section is being actively discussed by the development team, so use the docstring interpolation only if necessary. This section has been left in place for now because this interpolation is part of the existing documentation.

Since Matplotlib uses a lot of pass-through kwargs, e.g., in every function that creates a line (plot, semilogx, semilogy, etc.), it can be difficult for the new user to know which kwargs are supported. Matplotlib uses a docstring interpolation scheme to support documentation of every function that takes a **kwargs. The requirements are:

  1. single point of configuration so changes to the properties don't require multiple docstring edits.

  2. as automated as possible so that as properties change, the docs are updated automatically.

The @_docstring.interpd decorator implements this. Any function accepting Line2D pass-through kwargs, e.g., matplotlib.axes.Axes.plot, can list a summary of the Line2D properties, as follows:

# in axes.py
def plot(self, *args, **kwargs):
    Some stuff omitted

    Other Parameters
    scalex, scaley : bool, default: True
        These parameters determine if the view limits are adapted to the
        data limits. The values are passed on to `autoscale_view`.

    **kwargs : `.Line2D` properties, optional
        *kwargs* are used to specify properties like a line label (for
        auto legends), linewidth, antialiasing, marker face color.

        >>> plot([1, 2, 3], [1, 2, 3], 'go-', label='line 1', linewidth=2)
        >>> plot([1, 2, 3], [1, 4, 9], 'rs', label='line 2')

        If you specify multiple lines with one plot call, the kwargs apply
        to all those lines. In case the label object is iterable, each
        element is used as labels for each set of data.

        Here is a list of available `.Line2D` properties:


The %(Line2D:kwdoc) syntax makes interpd lookup an Artist subclass named Line2D, and call artist.kwdoc on that class. artist.kwdoc introspects the subclass and summarizes its properties as a substring, which gets interpolated into the docstring.

Note that this scheme does not work for decorating an Artist's __init__, as the subclass and its properties are not defined yet at that point. Instead, @_docstring.interpd can be used to decorate the class itself -- at that point, kwdoc can list the properties and interpolate them into __init__.__doc__.

Inheriting docstrings#

If a subclass overrides a method but does not change the semantics, we can reuse the parent docstring for the method of the child class. Python does this automatically, if the subclass method does not have a docstring.

Use a plain comment # docstring inherited to denote the intention to reuse the parent docstring. That way we do not accidentally create a docstring in the future:

class A:
    def foo():
        """The parent docstring."""

class B(A):
    def foo():
        # docstring inherited

Adding figures#

As above (see Including figures and files), figures in the examples gallery can be referenced with a .. plot:: directive pointing to the python script that created the figure. For instance the legend docstring references the file examples/text_labels_and_annotations/legend.py:



.. plot:: gallery/text_labels_and_annotations/legend.py

Note that examples/text_labels_and_annotations/legend.py has been mapped to gallery/text_labels_and_annotations/legend.py, a redirection that may be fixed in future re-organization of the docs.

Plots can also be directly placed inside docstrings. Details are in matplotlib.sphinxext.plot_directive. A short example is:



.. plot::
   import matplotlib.image as mpimg
   img = mpimg.imread('_static/stinkbug.png')
   imgplot = plt.imshow(img)

An advantage of this style over referencing an example script is that the code will also appear in interactive docstrings.

Writing examples and tutorials#

Examples and tutorials are python scripts that are run by Sphinx Gallery to create a gallery of images in the /doc/gallery and /doc/tutorials directories respectively. To exclude an example from having an plot generated insert "sgskip" somewhere in the filename.

The format of these files is relatively straightforward. Properly formatted comment blocks are treated as ReST text, the code is displayed, and figures are put into the built page.

For instance the example Simple Plot example is generated from /examples/lines_bars_and_markers/simple_plot.py, which looks like:

Simple Plot

Create a simple plot.
import matplotlib.pyplot as plt
import numpy as np

# Data for plotting
t = np.arange(0.0, 2.0, 0.01)
s = 1 + np.sin(2 * np.pi * t)

# Note that using plt.subplots below is equivalent to using
# fig = plt.figure and then ax = fig.add_subplot(111)
fig, ax = plt.subplots()
ax.plot(t, s)

ax.set(xlabel='time (s)', ylabel='voltage (mV)',
       title='About as simple as it gets, folks')

The first comment block is treated as ReST text. The other comment blocks render as comments in Simple Plot.

Tutorials are made with the exact same mechanism, except they are longer, and typically have more than one comment block (i.e. Quick start guide). The first comment block can be the same as the example above. Subsequent blocks of ReST text are delimited by a line of ### characters:

Simple Plot

Create a simple plot.

# Second plot
# ===========
# This is a second plot that is very nice

fig, ax = plt.subplots()

In this way text, code, and figures are output in a "notebook" style.


Moving documentation#

Sometimes it is desirable to move or consolidate documentation. With no action this will lead to links either going dead (404) or pointing to old versions of the documentation. Preferable is to replace the old page with an html refresh that immediately redirects the viewer to the new page. So, for example we move /doc/topic/old_info.rst to /doc/topic/new_info.rst. We remove /doc/topic/old_info.rst and in /doc/topic/new_info.rst we insert a redirect-from directive that tells sphinx to still make the old file with the html refresh/redirect in it (probably near the top of the file to make it noticeable)

.. redirect-from:: /topic/old_info

In the built docs this will yield an html file /build/html/topic/old_info.html that has a refresh to new_info.html. If the two files are in different subdirectories:

.. redirect-from:: /old_topic/old_info2

will yield an html file /build/html/old_topic/old_info2.html that has a (relative) refresh to ../topic/new_info.html.

Use the full path for this directive, relative to the doc root at https://matplotlib.org/stable/. So /old_topic/old_info2 would be found by users at http://matplotlib.org/stable/old_topic/old_info2. For clarity, do not use relative links.

Generating inheritance diagrams#

Class inheritance diagrams can be generated with the Sphinx inheritance-diagram directive.


.. inheritance-diagram:: matplotlib.patches matplotlib.lines matplotlib.text
   :parts: 2
Inheritance diagram of matplotlib.patches, matplotlib.lines, matplotlib.text