[SciPy-dev] Docstring standards for NumPy and SciPy

Norbert Nemec Norbert.Nemec.list at gmx.de
Mon Jan 22 14:18:26 CST 2007


Nice!

I'm wondering whether the default values of optional arguments should be 
mentioned in the docstrings?


Travis Oliphant wrote:
> There was a lively discussion on the SciPy List before Christmas 
> regarding establishing a standard for documentation strings for NumPy / 
> SciPy.
>
> I am very interested in establishing such a standard.  A hearty thanks 
> goes to William Stein for encouraging the discussion.   I hope it is 
> very clear that the developers of NumPy / SciPy are quite interested in 
> good documentation strings but recognize that producing them can be 
> fairly tedious and un-interesting work.  This is the best explanation I 
> can come up with for the relative paucity of documentation rather than 
> some underlying agenda *not* to produce them.  I suspect a standard has 
> not been established largely because of all the discussions taking place 
> within the documentation communities of epydoc, docutils, etc.  and a 
> relative unclarity on what to do about Math in docstrings.
>
> I'd like to get something done within the next few days (like placing 
> the standard on a wiki and/or placing a HOWTO_DOCUMENT file in the 
> distribution of NumPy). 
>
> My preference is to use our own basic format for documentation with 
> something that will translate the result into something that the epydoc 
> package can process (like epytext or reStructuredText).  The reason, I'd 
> like to use our own simple syntax, is that I'm not fully happy with 
> either epytext or reStructuredText.    In general, I don't like a lot of 
> line-noise and "formatting" extras.  Unfortuntately both epytext and 
> reStructuredText seem to have their fair share of such things.
>
> Robert wrote some great documentation for a few functions (apparently 
> following a reStructuredText format). While I liked that he did this, it 
> showed me that I don't very much like all the line-noise needed for 
> structured text.
>
> I've looked through a large number of documentation strings that I've 
> written over the years and believe that the following format suffices.   
> I would like all documentation to follow this format. 
>
> This format attempts to be a combination of epytext and restructured 
> text with additions for latex-math.  The purpose is to make a docstring 
> readable but also allowing for some structured text directives.  At some 
> point we will have a sub-routine that will translate docstrings in this 
> format to pure epytext or pure restructured text.
>
> """
> one-line summary not using variable names or the function name
>
> A few sentences giving an extended description.
>
> Inputs:
>    var1      -- Explanation
>    variable2 -- Explanation
>
> Outputs:  named, list, of, outputs
>    named   -- explanation
>    list    -- more detail
>    of      -- blah, blah.
>    outputs -- even more blah
>
> Additional Inputs:  
>    kwdarg1 -- A little-used input not always needed.
>    kwdarg2 -- Some keyword arguments can and should be given in Inputs
>               Section.  This is just for "little-used" inputs.
>
> Algorithm:
>    Notes about the implemenation algorithm (if needed).
>
>    This can have multiple paragraphs as can all sections.
>
> Notes:
>    Additional notes if needed
>
> Authors:
>    name (date):  notes about what was done
>    name (date):  major documentation updates can be included here also.
>
> See also:
>    * func1 -- any notes about the relationship
>    * func2 --
>    * func3 --
>    (or this can be a comma separated list)
>    func1, func2, func3
>
>    (For NumPy functions, these do not need to have numpy. namespace in 
> front of them)
>    (For SciPy they don't need the scipy. namespace in front of them).
>    (Use np and sp for abbreviations to numpy and scipy if you need to 
> reference
>       the other package).
>
> Examples:
>    examples in doctest format
>
> Comments:
>    This section should include anything that should not be displayed in 
> a help
>    or other hard-copy output.  Such things as substitution-directed 
> directives
>    should go here.
> """
>
> Additional Information:
>
> For paragraphs, indentation is significant and indicates indentation in 
> the output.   New paragraphs are marked with blank line.
>
> Text-emphasis:
>
> Use *italics*, **bold**, and `courier` if needed in any explanations 
> (but not for variable names and doctest code or multi-line code)
>
> Math:
>  
> Use \[...\] or $...$ for math in latex format (remember to use the 
> raw-format for your text string in such cases). Place it in a 
> new-paragraph for displaystyle or in-line for inline style.
>
>
> References:
>
> Use L{reference-link} for any code links (except in the see-also 
> section).  The reference-link should
> contain the full path-name (unless the function is in the same 
> name-space as this one is.
>
> Use http://  for any URL's
>
> Lists:
>
>   * item1
>     - subitem
>       + subsubitem
>   * item2
>   * item3
>
> or
>
>   1. item1
>      a. subitem
>         i.  subsubitem1
>         ii. subsubitem2
>   2. item2
>   3. item3
>
> for lists.
>
> Definitions:
>
>  descripition
>     This is my description
>     for any definitions needed.
>
> Addtional Code-blocks:
>
> {{{
> for multi-line code-blocks that are not examples to be run but should be 
> formatted as code.
> }}}
>
> Tables:
>
> Tables should be constructed as either:
>
>          +------------------------+------------+----------+
>          | Header row, column 1   | Header 2   | Header 3 |
>          +========================+============+==========+
>          | body row 1, column 1   | column 2   | column 3 |
>          +------------------------+------------+----------+
>          | body row 2             | Cells may span        |
>          +------------------------+-----------------------+
>
> or 
>
>          || Header row, column 1 || Header 2    || Header 3  ||
>          -------------------------------------------------------
>          || body row, column 1   || column 2    || column 3  ||
>          || body row 2           |||| Cells may span columns || 
>
>
> Footnotes:
>
> [1] or [CITATION3]  for Footnotes which are placed at the bottom of the 
> docstring as
>
> [1] Footnote
> [CITATION3] Additional note.
>
>
> Substitution:
>
> Use |somename|{optional text} with
>
> (the next line is placed at the bottom of the docstring in the Comments: 
> section)
> .. |somename| image::myfile.png
>
> or
>
> .. |somename| somedirective::
>  
>    {optional text}
>
> for placing restructured text directives in the main text.
>
>
> Please address comments to this proposal, very soon.  I'd like to 
> finalize it within a few days.
>
> -Travis
>
>
>  
>
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>   



More information about the Scipy-dev mailing list