Docstrings: docs API rendering

[jeffjennings]

• Closes #234. Does so with some indents (rather than changing from the numpy docstring format to napoleon) because I don't find napoleon readable for long docstrings when looking at the code. I checked the API with make clean --> make html.

• Adds mpol.onedim to the docs API.

[iancze]

Thanks for these changes, however, I think it is important to use the same docstring style throughout the code. It's more mental effort for the developer to maintain and write correct documentation when we have to switch between formats depending on the function or class. And sphinx seems to have some cracks through which doc bugs fall through when docstrings are mixed format (side-note, is there a more strict version of sphinx build we can use to catch these? I thought we were already doing this).

So I would either suggest we stick with napoleon or modify everything to numpy docstring format (a considerable task). Can you elaborate on what's difficult to read with napoleon? I find we have some fairly long docstrings that still (to me, at least) look good in code and napoleon is certainly more concise to write, which are the reasons I originally chose it over numpy format.

[jeffjennings]

Yes it's just that when using VSCode or similar, reading the docstring for something like fourier.NuFFT is annoying because the line length far exceeds the recommended Python line length and requires a lot of scrolling. Several of my docstrings have long lines, and it looks like there are ~50 of them with the numpy docstring format. Since the docs render correctly, I'd prefer to focus on what I think are much more urgent issues than re-format all of these.

[iancze]

OK, definitely agree this is not a high priority use of your time :) But I think we should converge on a single docstring style for the codebase as a longer term goal.

I use VSCode too and the docstrings render fine for me (virtual WordWrap set to on), which seems necessary for editing most kinds of documents anyway.