@@ -198,33 +198,10 @@ Embedding the function's signature in the docstring is unnecessary because it
198
198
can easily be obtained using the `inspect ` module, and doesn't provide much
199
199
additional information.
200
200
201
- For more complex cases, there are a couple generally accepted styles used
202
- when writing documentation. The first of these uses reStructuredText syntax
203
- to format arguments and other elements of the docstring appropriately::
204
-
205
- def function1(self, arg1, arg2, arg3):
206
- """A short, one line summary of the function.
207
-
208
- This is a longer explanation, which may include math with
209
- latex syntax :math:`\\alpha`.
210
-
211
- :param arg1: the first value
212
- :param arg2: the first value
213
- :param arg3: the first value
214
- :type arg1: int, float,...
215
- :type arg2: int, float,...
216
- :type arg3: int, float,...
217
- :returns: arg1/arg2 +arg3
218
- :rtype: int, float
219
- """
220
- return arg1/arg2 + arg3
221
-
222
- `thomas-cokelaer.info `_ has a fairly complete article showing more examples for
223
- this style.
224
-
225
- While the end result is parsed by Sphinx and renders correctly in a browser, it
226
- isn't the easiest of formats to read. The `NumPy style `_ is a lot nicer to read,
227
- however it consumes a lot more real estate than the previous style::
201
+ For more detailed documentation of code a popular style is the one used for the
202
+ Numpy project, often called `Numpy style `_ docstrings. While it can take up a
203
+ few more lines than usual, it allows the developer to include a lot more
204
+ information about a method, function, or class. ::
228
205
229
206
def random_number_generator(arg1, arg2):
230
207
"""
0 commit comments