1
- MEP10: Docstring consistency
2
- ============================
1
+ ==============================
2
+ MEP10: Docstring consistency
3
+ ==============================
3
4
.. contents ::
4
5
:local:
5
6
6
7
Status
7
- ------
8
+ ======
8
9
9
10
**Progress **
10
11
11
12
Targeted for 1.3
12
13
13
14
Branches and Pull requests
14
- --------------------------
15
+ ==========================
15
16
16
17
#1665
17
18
#1757
18
19
#1795
19
20
20
21
Abstract
21
- --------
22
+ ========
22
23
23
24
matplotlib has a great deal of inconsistency between docstrings. This
24
25
not only makes the docs harder to read, but it is harder on
@@ -36,15 +37,15 @@ Building the documentation takes a long time and uses a `make.py`
36
37
script rather than a Makefile.
37
38
38
39
Detailed description
39
- --------------------
40
+ ====================
40
41
41
42
There are number of new tools and conventions available since
42
43
matplotlib started using Sphinx that make life easier. The following
43
44
is a list of proposed changes to docstrings, most of which involve
44
45
these new features.
45
46
46
47
Numpy docstring format
47
- ''''''''''''''''''''''
48
+ ----------------------
48
49
49
50
`Numpy docstring format
50
51
<https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt> `_:
@@ -55,7 +56,7 @@ own, but this is a strong choice, as it's well used and understood in
55
56
the Numpy/Scipy community.
56
57
57
58
Cross references
58
- ''''''''''''''''
59
+ ----------------
59
60
60
61
Most of the docstrings in matplotlib use explicit "roles" when linking
61
62
to other items, for example: ``:func:`myfunction` ``. As of Sphinx
@@ -67,7 +68,7 @@ a current module, so links like ```~matplotlib.axes.Axes.set_xlim```
67
68
could be written as ```~axes.Axes.set_xlim` ``.
68
69
69
70
Overriding signatures
70
- '''''''''''''''''''''
71
+ ---------------------
71
72
72
73
Many methods in matplotlib use the ``*args `` and ``**kwargs `` syntax
73
74
to dynamically handle the keyword arguments that are accepted by the
@@ -104,7 +105,7 @@ The explicit signature will replace the actual Python one in the
104
105
generated documentation.
105
106
106
107
Linking rather than duplicating
107
- '''''''''''''''''''''''''''''''
108
+ -------------------------------
108
109
109
110
Many of the docstrings include long lists of accepted keywords by
110
111
interpolating things into the docstring at load time. This makes the
@@ -117,7 +118,7 @@ purpose is for help. The docstrings that refer to these tables should
117
118
link to them, rather than including them verbatim.
118
119
119
120
autosummary extension
120
- '''''''''''''''''''''
121
+ ---------------------
121
122
122
123
The Sphinx autosummary extension should be used to generate summary
123
124
tables, that link to separate pages of documentation. Some classes
@@ -126,7 +127,7 @@ one method per page, whereas smaller classes should have all of their
126
127
methods together.
127
128
128
129
Examples linking to relevant documentation
129
- ''''''''''''''''''''''''''''''''''''''''''
130
+ ------------------------------------------
130
131
131
132
The examples, while helpful at illustrating how to use a feature, do
132
133
not link back to the relevant docstrings. This could be addressed by
@@ -136,15 +137,15 @@ docstrings could easily include references to any other part of the
136
137
documentation.
137
138
138
139
Documentation using help() vs a browser
139
- ''''''''''''''''''''''
140
+ ---------------------------------------
140
141
141
142
Using Sphinx markup in the source allows for good-looking docs in your
142
143
browser, but the markup also makes the raw text returned using help()
143
144
look terrible. One of the aims of improving the docstrings should be
144
145
to make both methods of accessing the docs look good.
145
146
146
147
Implementation
147
- --------------
148
+ ==============
148
149
149
150
1. The numpydoc extensions should be turned on for matplotlib. There
150
151
is an important question as to whether these should be included in
@@ -181,12 +182,12 @@ Steps 1, 2, and 3 are interdependent. 4 and 5 may be done
181
182
independently, though 5 has some dependency on 3.
182
183
183
184
Backward compatibility
184
- ----------------------
185
+ ======================
185
186
186
187
As this mainly involves docstrings, there should be minimal impact on
187
188
backward compatibility.
188
189
189
190
Alternatives
190
- ------------
191
+ ============
191
192
192
193
None yet discussed.
0 commit comments