You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: wrap Sphinx style long parameter descriptions (#201)
* feat: add new --style argument
* test: for new --style argument
* doc: for new --style argument
* fix: long description before list not wrapping
* Merge branch `master`
* Merge branch release/v1.7.0
* fix: not finding literal blocks
* chore: add pre-commit-config.yaml
* chore: add pre-commit-config.yaml
* refactor: change FIELD_REGEX to SPHINX_REGEX
Copy file name to clipboardExpand all lines: docs/source/requirements.rst
+30-20Lines changed: 30 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -51,17 +51,31 @@ Thus, an autoformatting tool:
51
51
* Would be nice to produce as much output that satisfies the *methodology* requirements.
52
52
* Would be nice to provide arguments to allow the user to turn on/off each *methodology* requirement the tool supports.
53
53
54
-
Docstring Syntax
55
-
----------------
54
+
Docstring Style
55
+
---------------
56
56
57
-
There are at least three "flavors" of docstrings in common use today; Sphinx,
58
-
NumPy, and Google. Each of these docstring flavors follow the PEP 257
59
-
*convention* requirements. What differs between the three docstring flavors
60
-
is the reST syntax used in the elaborate description of the multi-line
57
+
There are at least four "flavors" of docstrings in common use today;
58
+
Epydoc, Sphinx, NumPy, and Google. Each of these docstring flavors follow the
59
+
PEP 257 *convention* requirements. What differs between the three docstring
60
+
flavors is the reST syntax used in the parameter description of the multi-line
61
61
docstring.
62
62
63
63
For example, here is how each syntax documents function arguments.
64
64
65
+
Epydoc syntax:
66
+
67
+
.. code-block::
68
+
69
+
@type num_dogs: int
70
+
@param num_dogs: the number of dogs
71
+
72
+
Sphinx syntax:
73
+
74
+
.. code-block::
75
+
76
+
:param param1: The first parameter, defaults to 1.
77
+
:type: int
78
+
65
79
Google syntax:
66
80
67
81
.. code-block::
@@ -78,13 +92,6 @@ NumPy syntax:
78
92
param1 : int
79
93
The first parameter.
80
94
81
-
Sphinx syntax:
82
-
83
-
.. code-block::
84
-
85
-
:param param1: The first parameter, defaults to 1.
86
-
:type: int
87
-
88
95
Syntax is also important to ``Docutils``. An autoformatter should be aware of
89
96
syntactical directives so they can be placed properly in the structure of the
90
97
docstring. To accommodate the various syntax flavors used in docstrings, a
@@ -201,8 +208,14 @@ the requirement falls in, the type of requirement, and whether
201
208
' docformatter_10.1.3.1', ' Shall maintain in-line links on one line even if the resulting line exceeds wrap length.', ' Derived', ' Shall', ' Yes [*PR #152*]'
202
209
' docformatter_10.1.3.2', ' Shall not place a newline between description text and a wrapped link.', ' Derived', ' Shall', ' Yes [PR #182]'
203
210
' docformatter_10.2', ' Should format docstrings using NumPy style.', ' Style', ' Should', ' No'
211
+
' docformatter_10.2.1', ' Shall ignore docstrings in other styles when using NumPy style.', ' Shall', ' Yes'
212
+
' docformatter_10.2.2', ' Shall wrap NumPy-style parameter descriptions that exceed wrap length when using NumPy style.', ' Shall', ' No'
204
213
' docformatter_10.3', ' Should format docstrings using Google style.', ' Style', ' Should', ' No'
205
-
' docformatter_10.4', ' Should format docstrings using Sphinx style.', ' Style', ' Should', ' No'
214
+
' docformatter_10.3.1', ' Shall ignore docstrings in other styles when using Google style.', ' Shall', ' Yes'
215
+
' docformatter_10.3.2', ' Shall wrap Google-style parameter descriptions that exceed wrap length when using Google style.', ' Shall', ' No'
216
+
' docformatter_10.4', ' Should format docstrings using Sphinx style.', ' Style', ' Should', ' Yes'
217
+
' docformatter_10.4.1', ' Shall ignore docstrings in other styles when using Sphinx style.', ' Shall', ' Yes'
218
+
' docformatter_10.4.2', ' Shall wrap Sphinx-style parameter descriptions that exceed wrap length when using Sphinx style.', ' Shall', ' Yes'
206
219
' docformatter_10.5', ' Should format docstrings compatible with black.', ' Style', ' Should', ' Yes [PR #192]'
207
220
' docformatter_10.5.1', ' Should wrap summaries at 88 characters by default in black mode.', ' Style', ' Should', ' Yes'
208
221
' docformatter_10.5.2', ' Should wrap descriptions at 88 characters by default in black mode.', ' Style', ' Should', ' Yes'
@@ -244,6 +257,9 @@ with *convention* requirements.
244
257
``docformatter`` currently provides these arguments for *style* requirements.
245
258
::
246
259
260
+
-s, --style [string, default sphinx]
261
+
name of the docstring syntax style to use for formatting parameter
262
+
lists.
247
263
--black [boolean, default False]
248
264
Boolean to indicate whether to format docstrings to be compatible
249
265
with black.
@@ -306,12 +322,6 @@ The following are new arguments that are needed to implement **should** or
306
322
Boolean to indicate whether to wrap one-line docstrings. Provides
307
323
option for requirement PEP_257_4.1.
308
324
309
-
The following are new *style* arguments needed to accommodate the various style options:
0 commit comments