-
Notifications
You must be signed in to change notification settings - Fork 795
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
refactor(docs, ruff): Add pydocstyle
rules
#3493
Conversation
Based on vega#3466 (comment) With some additional ignores added during test runs on `/v5/schema/*.py`
I should have updated in vega#3444 but the problem didn't become apparent until running through `ruff`
Rules are strictly only applied to autogenerated code currently, until the final style has been approved
@binste @mattijn @joelostblom @jonmmease I've left this on draft for discussion, with the hope to apply whatever style is agreed upon to the rest of the codebase. Just wanted to be clear that this is ready for "review", but I'm not looking to merge only the changes to generated code, if that makes sense? |
All good from my side. Just one note, that you are surely already aware of, many code including docstrings is auto generated. Thus if you want to apply numpydoc formatting style to them it should be within the code that generate this. |
I now see your line stating:
👍 |
Thanks @mattijn For reference, running on the rest of the codebase: # [tool.ruff.lint.per-file-ignores]
# Ignore `D` rules everywhere *except* for auto-generated code.
# "!altair/vegalite/v5/schema/*.py" = ["D","D213"] >>> ruff check --statistics
Found 472 errors.
[*] 410 fixable with the `--fix` option.
195 D400 [*] ends-in-period
174 D213 [*] multi-line-summary-second-line
59 D205 [ ] blank-line-after-summary
13 D200 [*] fits-on-one-line
11 D202 [*] no-blank-line-after-function
6 D407 [*] dashed-underline-after-section
4 D403 [*] first-line-capitalized
3 D209 [*] new-line-after-last-paragraph
3 D404 [ ] docstring-starts-with-this
1 D300 [*] triple-single-quotes
1 D406 [*] new-line-after-section-name
1 D410 [*] no-blank-line-after-section
1 D411 [*] no-blank-line-before-section Showing the diff wouldn't be very helpful, but if you're interested in seeing examples for each code at pydocstyle-d All 472 violations
|
*Excluding altair/utils/schemapi.py
Propagates `schemapi` fixes
After further thought, the non-generated code provides a greater range of examples. See #3493 (commits) for more variety.
This part still applies, I'll probably leave that until there's another approval. I thought there was more config to it, but it seems that it is just docstring-code-line-length The default is UpdateJust finished a very informal survey of projects listed in https://github.com/astral-sh/ruff?tab=readme-ov-file#whos-using-ruff I planned to collect some data, but almost all the projects I looked into either used the default The following use the default:
Ibis was the only one I found with it set. [tool.ruff.format]
docstring-code-format = true
docstring-code-line-length = 88 # ibis |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Configuration works for me as well. Thanks for setting it up and implementing the manual fixes! Adding my approval as well as a confirmation :)
Thanks @binste @mattijn for the approvals, apologies that I'm asking for another If anyone has any strong opinions on the change in My suggestion would be to revisit during the review of That will end up with more docstring code block examples once finished. |
I left this as a TODO during vega#3493 and only spotted it after merging
I left this as a TODO during #3493 and only spotted it after merging
Follow-up discussed in: #3430 (comment)
This PR defines and applies a docstring style, for consistent and readable docs.
The style is based on numpydoc with some tweaks that have already been introduced to
expr
in #3466 (comment)I have not added any new rules to that config.
However, testing on the generated code identified some rules that needed to be ignored.
This style is strictly applied to generated code only, until the final style has been approved.
One caveat is that docstring code formatting rules are not enabled yet - as they only affect non-generated code.