Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support numpy or Google docstrings #60

Open
leotrs opened this issue Aug 25, 2020 · 14 comments
Open

Support numpy or Google docstrings #60

leotrs opened this issue Aug 25, 2020 · 14 comments
Labels
C: style Relates to docstring format style (e.g., Google, NumPy, Sphinx) P: enhancement Feature that is outside the scope of PEP 257 U: low A relatively low urgency issue
Milestone

Comments

@leotrs
Copy link

leotrs commented Aug 25, 2020

Are there any plans to do this? Is this already implemented?

@Pacu2
Copy link
Contributor

Pacu2 commented Dec 30, 2020

We could add a new flag --convention same as pydocstyle does.

@erwanp
Copy link

erwanp commented Jan 21, 2021

Would be a very nice feature !

@ubalklen
Copy link

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.

@mohammad7t
Copy link

mohammad7t commented Mar 31, 2022

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.

@ubalklen
Copy link

Thanks @mhsekhavat. I've just tried pyment, but it doesn't wrap long lines.

@weibullguy weibullguy added the P: enhancement Feature that is outside the scope of PEP 257 label Jul 24, 2022
@weibullguy weibullguy added the C: style Relates to docstring format style (e.g., Google, NumPy, Sphinx) label Aug 6, 2022
@Goldziher
Copy link

any update on this?

@weibullguy
Copy link
Member

@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
Copy link

@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 😉

@kdeldycke
Copy link

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.

@weibullguy
Copy link
Member

@kdeldycke I am aware of it now, thanks! It looks promising for dealing with the various syntax flavors.

@ssweber
Copy link

ssweber commented Apr 8, 2023

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.

@simonprovost
Copy link

Would be very needed !!!

@weibullguy weibullguy modified the milestones: v2.0.0, v1.8.0 May 15, 2023
@weibullguy weibullguy added P: enhancement Feature that is outside the scope of PEP 257 and removed P: enhancement Feature that is outside the scope of PEP 257 labels Jun 7, 2023
@github-actions github-actions bot added the U: low A relatively low urgency issue label Jun 7, 2023
@mcarans
Copy link

mcarans commented Nov 27, 2023

This has been marked as low urgency, but for me, the lack of support for Google doscstrings means I cannot use docformatter.

@nexushoratio
Copy link

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 heavenshell/py-doq#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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: style Relates to docstring format style (e.g., Google, NumPy, Sphinx) P: enhancement Feature that is outside the scope of PEP 257 U: low A relatively low urgency issue
Projects
None yet
Development

No branches or pull requests