Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 216f042

Browse files
committed
DOC: Minor enhancements to documenting_mpl
1 parent 2f897dc commit 216f042

File tree

1 file changed

+75
-25
lines changed

1 file changed

+75
-25
lines changed

doc/devel/documenting_mpl.rst

Lines changed: 75 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -43,16 +43,17 @@ guide, developers guide, api reference, and FAQs. The documentation suite is
4343
built as a single document in order to make the most effective use of cross
4444
referencing.
4545

46-
.. note::
47-
48-
An exception to this are the directories :file:`examples` and
49-
:file:`tutorials`, which exist in the root directory. These contain Python
50-
files that are built by `Sphinx Gallery`_. When the docs are built,
51-
the directories :file:`docs/gallery` and :file:`docs/tutorials`
52-
are automatically generated. Do not edit the rst files in :file:docs/gallery
53-
and :file:docs/tutorials, as they are rebuilt from the original sources in
54-
the root directory.
55-
46+
Sphinx_ also creates ``.rst`` files that are staged in :file:`doc/api` from
47+
the docstrings of the classes in the Matplotlib library. Except for
48+
:file:`doc/api/api_changes/`, these ``.rst`` are created when the
49+
documentation is built.
50+
51+
Similarly, the contents of :file:`docs/gallery` and :file:`docs/tutorials` are
52+
generated by the `Sphinx Gallery`_ from the sources in :file:`examples` and
53+
:file:`tutorials`. These sources consist of python scripts that have ReST
54+
documentation built into their comments. Again, don't directly edit the
55+
``.rst`` files in :file:`docs/gallery` and :file:`docs/tutorials` as they are
56+
regenerated when the documentation are built.
5657

5758
Additional files can be added to the various guides by including their base
5859
file name (the .rst extension is not necessary) in the table of contents.
@@ -91,12 +92,19 @@ The list of commands and flags for ``make.py`` can be listed by running
9192
Writing new documentation
9293
=========================
9394

95+
As noted above, most documentation is either in the docstring of individual
96+
classes and methods, in explicit ``.rst`` files, or in examples and tutorials.
97+
98+
Writing self-documenting docstrings
99+
-----------------------------------
100+
94101
Most documentation lives in "docstrings". These are comment blocks in source
95102
code that explain how the code works. All new or edited docstrings should
96103
conform to the numpydoc guidelines. These split the docstring into a number
97104
of sections - see
98105
https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt for more
99-
details and a guide to how docstrings should be formatted.
106+
details and a guide to how docstrings should be formatted. These docstrings
107+
eventually populate the :file:`doc/api` directory.
100108

101109
An example docstring looks like:
102110

@@ -136,28 +144,54 @@ An example docstring looks like:
136144
axhline: horizontal line across the axes
137145
"""
138146
147+
See the `~.Axes.hlines` documentation for how this renders.
148+
139149
The Sphinx website also contains plenty of documentation_ concerning ReST
140150
markup and working with Sphinx in general.
141151

142152
Linking to other code
143-
---------------------
153+
~~~~~~~~~~~~~~~~~~~~~
144154
To link to other methods, classes, or modules in Matplotlib you can encase
145155
the name to refer to in back ticks, for example:
146156

147157
.. code-block:: python
148158
149159
`~matplotlib.collections.LineCollection`
150160
151-
It is also possible to add links to code in Python, Numpy, Scipy, or Pandas.
152-
Sometimes it is tricky to get external Sphinx linking to work; to check that
153-
a something exists to link to the following shell command outputs a list of all
154-
objects that can be referenced (in this case for Numpy)::
161+
returns a link to the documentation of
162+
`~matplotlib.collections.LineCollection`. If we want the full path of the
163+
class to be shown then we omit the tilde:
164+
165+
.. code-block:: python
166+
167+
`matplotlib.collections.LineCollection`
168+
169+
to get `matplotlib.collections.LineCollection`. Its often not
170+
necessary to fully specify the class hierarchy:
171+
172+
.. code-block:: python
173+
174+
`~.LineCollection`
175+
176+
links just as well: `~.LineCollection`.
177+
178+
Other packages can also be linked via ``intersphinx``:
179+
180+
.. code-block:: Python
181+
182+
`numpy.mean`
183+
184+
will return this link: `numpy.mean`. This works for Python, Numpy, Scipy,
185+
and Pandas. Sometimes it is tricky to get external Sphinx linking to work; to
186+
check that a something exists to link to the following shell command outputs
187+
a list of all objects that can be referenced (in this case for Numpy)::
155188

156189
python -m sphinx.ext.intersphinx 'https://docs.scipy.org/doc/numpy/objects.inv'
157190

158191

159192
Function arguments
160-
------------------
193+
~~~~~~~~~~~~~~~~~~
194+
161195
Function arguments and keywords within docstrings should be referred to using
162196
the ``*emphasis*`` role. This will keep Matplotlib's documentation consistent
163197
with Python's documentation:
@@ -180,13 +214,16 @@ nor the ````literal```` role:
180214
Please do not describe ``argument`` like this.
181215
182216
Setters and getters
183-
-------------------
184-
Matplotlib uses artist introspection of docstrings to support properties.
185-
All properties that you want to support through `~.pyplot.setp` and
186-
`~.pyplot.getp` should have a ``set_property`` and ``get_property`` method in
187-
the `~.matplotlib.artist.Artist` class. The setter methods use the docstring
188-
with the ACCEPTS token to indicate the type of argument the method accepts.
189-
e.g., in `.Line2D`:
217+
~~~~~~~~~~~~~~~~~~~
218+
219+
Artist properties are implemented using setter and getter methods (because
220+
Matplotlib predates the introductions of the `property` decorator in Python).
221+
By convention, these setters and getters are named ``set_PROPERTYNAME`` and
222+
``get_PROPERTYNAME``; the list of properties thusly defined on an artist and
223+
their values can be listed by the `~.pyplot.setp` and `~.pyplot.getp` functions.
224+
225+
Property setter methods should indicate the values they accept using a (legacy)
226+
special block in the docstring, starting with ``ACCEPTS``, as follows:
190227

191228
.. code-block:: python
192229
@@ -198,8 +235,21 @@ e.g., in `.Line2D`:
198235
ACCEPTS: [ '-' | '--' | '-.' | ':' | 'steps' | 'None' | ' ' | '' ]
199236
"""
200237
238+
The ACCEPTS block is used to render a table of all properties and their
239+
acceptable values in the docs; it can also be displayed using, e.g.,
240+
``plt.setp(Line2D)`` (all properties) or ``plt.setp(Line2D, 'linestyle')``
241+
(just one property).
242+
201243
Keyword arguments
202-
-----------------
244+
~~~~~~~~~~~~~~~~~
245+
246+
.. note::
247+
248+
The information in this section is being actively discussed by the
249+
development team, so use the docstring interpolation only if necessary.
250+
This section has been left in place for now because this interpolation
251+
is part of the existing documentation.
252+
203253
Since Matplotlib uses a lot of pass-through ``kwargs``, e.g., in every function
204254
that creates a line (`~.pyplot.plot`, `~.pyplot.semilogx`, `~.pyplot.semilogy`,
205255
etc...), it can be difficult for the new user to know which ``kwargs`` are

0 commit comments

Comments
 (0)