@@ -198,33 +198,10 @@ Embedding the function's signature in the docstring is unnecessary because it
198198can easily be obtained using the `inspect ` module, and doesn't provide much
199199additional information.
200200
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. ::
228205
229206 def random_number_generator(arg1, arg2):
230207 """
0 commit comments