@@ -43,16 +43,17 @@ guide, developers guide, api reference, and FAQs. The documentation suite is
43
43
built as a single document in order to make the most effective use of cross
44
44
referencing.
45
45
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.
56
57
57
58
Additional files can be added to the various guides by including their base
58
59
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
91
92
Writing new documentation
92
93
=========================
93
94
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
+
94
101
Most documentation lives in "docstrings". These are comment blocks in source
95
102
code that explain how the code works. All new or edited docstrings should
96
103
conform to the numpydoc guidelines. These split the docstring into a number
97
104
of sections - see
98
105
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.
100
108
101
109
An example docstring looks like:
102
110
@@ -136,28 +144,54 @@ An example docstring looks like:
136
144
axhline: horizontal line across the axes
137
145
"""
138
146
147
+ See the `~.Axes.hlines ` documentation for how this renders.
148
+
139
149
The Sphinx website also contains plenty of documentation _ concerning ReST
140
150
markup and working with Sphinx in general.
141
151
142
152
Linking to other code
143
- ---------------------
153
+ ~~~~~~~~~~~~~~~~~~~~~
144
154
To link to other methods, classes, or modules in Matplotlib you can encase
145
155
the name to refer to in back ticks, for example:
146
156
147
157
.. code-block :: python
148
158
149
159
`~ matplotlib.collections.LineCollection`
150
160
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)::
155
188
156
189
python -m sphinx.ext.intersphinx 'https://docs.scipy.org/doc/numpy/objects.inv'
157
190
158
191
159
192
Function arguments
160
- ------------------
193
+ ~~~~~~~~~~~~~~~~~~
194
+
161
195
Function arguments and keywords within docstrings should be referred to using
162
196
the ``*emphasis* `` role. This will keep Matplotlib's documentation consistent
163
197
with Python's documentation:
@@ -180,13 +214,16 @@ nor the ````literal```` role:
180
214
Please do not describe ``argument`` like this.
181
215
182
216
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:
190
227
191
228
.. code-block :: python
192
229
@@ -198,8 +235,21 @@ e.g., in `.Line2D`:
198
235
ACCEPTS: [ '-' | '--' | '-.' | ':' | 'steps' | 'None' | ' ' | '' ]
199
236
"""
200
237
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
+
201
243
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
+
203
253
Since Matplotlib uses a lot of pass-through ``kwargs ``, e.g., in every function
204
254
that creates a line (`~.pyplot.plot `, `~.pyplot.semilogx `, `~.pyplot.semilogy `,
205
255
etc...), it can be difficult for the new user to know which ``kwargs `` are
0 commit comments