docformatter
docformatter copied to clipboard
Support numpy or Google docstrings
Are there any plans to do this? Is this already implemented?
We could add a new flag --convention
same as pydocstyle
does.
Would be a very nice feature !
While this is still open, I wonder what do people currently use to format their numpy/Google docstrings? I could not find any alternatives to docformatter, and it's hard to believe developers are doing this by hand and not losing their sanity in the process.
I could not find any alternatives to docformatter
@ubalklen there is also https://github.com/dadadel/pyment
The last time I tried it, it had a problem that running pyment -w .
(-w is for formatting files in-place) multiple times doesn't produce the same result (it keeps adding docstring for parameters that already have docstrings)
But that should be a solvable problem.
Thanks @mhsekhavat. I've just tried pyment, but it doesn't wrap long lines.
any update on this?
@Goldziher I recently started helping out with maintenance. I've been focusing on merging all the open PRs and addressing issues that were related to PEP 257 conventions. Once these are addressed, I'll release a new version (v1.5.0) of docformatter to PyPi. After that I plan to tackle the group of issues related to the various docstring styles (#43, #60, #68, #70, #78, #79). Once that group of issues is addressed, I'll release v1.6.0. Hopefully that'll happen in the next month or so.
@Goldziher I recently started helping out with maintenance. I've been focusing on merging all the open PRs and addressing issues that were related to PEP 257 conventions. Once these are addressed, I'll release a new version (v1.5.0) of docformatter to PyPi. After that I plan to tackle the group of issues related to the various docstring styles (#43, #60, #68, #70, #78, #79). Once that group of issues is addressed, I'll release v1.6.0. Hopefully that'll happen in the next month or so.
Sounds great. Lemme know when it's ready to test on a codebase 😉
Now that I'm thinking of it, I just stumbled upon the docstring_parser
library. @weibullguy, are you aware of it? Is it something you ever considered at one point? It seems to be a good library to abstract the support of ReST, Google, Numpydoc-style and Epydoc styles.
@kdeldycke I am aware of it now, thanks! It looks promising for dealing with the various syntax flavors.
This would be a great feature.
Am about to convert a library from sphinx-style to google, and will be rewrapping a bunch of lines by hand.
Another library that parses, if you’re not already aware, is Griffe, which is used by mkdocstrings.
Would be very needed !!!
This has been marked as low urgency, but for me, the lack of support for Google doscstrings means I cannot use docformatter.
what do people currently use to format their .../Google docstrings?
We did it by hand. And we liked it! (Though now that I'm no longer under G's thumb, I just started looking for such a tool and stumbled onto this issue.)
I could not find any alternatives to docformatter...
I just discovered https://github.com/heavenshell/py-doq which generates NEW docstrings, but explicitly will not update https://github.com/heavenshell/py-doq/issues/30
It seems to me that the various tools out there all touch on the subject, but none hits all of the bullet points (at least the ones I want):
- Create docstrings from scratch with the same (exactly, or kind of) reasoning as pylint will use to complain (e.g., min-length, no-docstring-rgx)
- Create docstrings that are almost-but-not-quite to documented specs (or generally, claim to follow documented guidelines for any X, except the rules they don't like and not let you easily make them right)
- Update docstrings as parms are added/removed/reordered
- Find the variety of config files consistently (IMO, the only thing pyproject.toml did was fulfill https://xkcd.com/927/, and even the it is suspect)