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

Document experimental string processing and docstring indentation #2106

Merged
merged 2 commits into from Apr 22, 2021
Merged

Document experimental string processing and docstring indentation #2106

merged 2 commits into from Apr 22, 2021

Conversation

felix-hilden
Copy link
Collaborator

@felix-hilden felix-hilden commented Apr 14, 2021

From #53: this PR adds short descriptions of #1053 and #1132 to the Black code style document.

Possible points of review/contention:

  • Has the processing changed since? Reading the changelog I don't think it has, but I haven't been around.
  • Doc placement: I think the "Strings" section is appropriate for both, unless another section for indentation is created. I appended the text to the section by default, and because "experimental" hints that maybe it shouldn't be the first thing to be introduced to the reader. I'm not sure about the docstring paragraph though. It is quite short, so maybe it ought to be merged with some other paragraph.

I don't think any of the checks apply, and skip news could also be added. Pre-commit did line up the text though.

Happy to make any changes you suggest!


Also, while running the install stuff, there was some sort of process pool termination when formatting the repository. Is that something that is expected to happen on Windows?

@felix-hilden
Copy link
Collaborator Author

felix-hilden commented Apr 14, 2021

Self-review!

So I had a look over the issue tracker, and #1740 implies the existence of further docstring processing (i.e. stripping white space), but I couldn't find the original source. I did find the original Docstring opinion issue, and several by Jelle fixing crashes on docstring modifications like removing trailing whitespace. But I got pretty lost pretty quickly.

Should we just add a mention about stripping white space? Alternatively, #1740 (or a follow-up PR) could add all the information about docstring contents.

I think the long-term solution to closing #53 could be to add a section to CONTRIBUTING.md where contributors are instructed to modify the Black code style document when making style changes. It would be nice to enforce it automatically, but I don't know if a CI check about requiring that is even possible. So manual review it is I guess.

@JelleZijlstra
Copy link
Collaborator

So I had a look over the issue tracker, and #1740 implies the existence of further docstring processing (i.e. stripping white space), but I couldn't find the original source. I did find the original Docstring opinion issue, and several by Jelle fixing crashes on docstring modifications like removing trailing whitespace. But I got pretty lost pretty quickly.

Did you try looking at the test cases for docstrings? That's probably the best way to find out all the things we change. I believe it's mostly about reindentation and stripping whitespace.

Also, thanks for contributing this! I'll take a more detailed look later.

@ichard26 ichard26 self-requested a review April 14, 2021 18:02
@ichard26 ichard26 added the skip news Pull requests that don't need a changelog entry. label Apr 14, 2021
@ichard26
Copy link
Collaborator

Yep, the docstring formatting Black does mostly boils down to reindenting and stripping whitespace, but there is an edge case where Black does move the quotes:

ichard26@acer-ubuntu:~/programming/oss/black$ cat test.py 
def test8():
    """Or like this.
    """
ichard26@acer-ubuntu:~/programming/oss/black$ black test.py --diff -q
--- test.py	2021-04-14 22:59:18.638257 +0000
+++ test.py	2021-04-14 22:59:33.679733 +0000
@@ -1,3 +1,2 @@
 def test8():
-    """Or like this.
-    """
+    """Or like this."""

This behaviour does have a report: #1635 but it's unclear whether this should exist (and therefore be documented) (@JelleZijlstra I'm personally of the opinion we should get consistent about this by either uniformingly moving quotes or not moving them at all)

Alternatively, #1740 (or a follow-up PR) could add all the information about docstring contents.

I am leaning towards letting the proposed PRs add the information on docstring reformatting just in case we reject one (seems unlikely but always a possibility), but I don't feel strongly about this.

I think the long-term solution to closing #53 could be to add a section to CONTRIBUTING.md where contributors are instructed to modify the Black code style document when making style changes. It would be nice to enforce it automatically, but I don't know if a CI check about requiring that is even possible. So manual review it is I guess.

Yeah I agree to add such a section in the contributing documentation (I'll probably end up doing it myself). In terms enforcing it automatically... yeah it would difficult to do that. I do want to write PR review documentation though, so I suppose we could mention checking for this there.

Also, while running the install stuff, there was some sort of process pool termination when formatting the repository. Is that something that is expected to happen on Windows?

One, that certainly shouldn't happen regardless of the platform and sounds like a bug. And two, is it I/O operation on closed file errors? This issue has been reported and fixed already but the fix hasn't been released yet (see GH-1664).

Copy link
Collaborator

@ichard26 ichard26 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than the docstring docs being incorrect I can't find anything to fault your documentation on.

Has the processing changed since?

Other than a lot of bugfixes, no IIRC the processing hasn't changed.

RE: Doc placement

I agree with your reasoning and I'm happy with where it is as of right now.

Excellent work and thank you for picking this up! I'll leave this for Jelle to review.

docs/the_black_code_style.md Outdated Show resolved Hide resolved
docs/the_black_code_style.md Outdated Show resolved Hide resolved
@ichard26 ichard26 added the T: documentation Improvements to the docs (e.g. new topic, correction, etc) label Apr 14, 2021
@felix-hilden
Copy link
Collaborator Author

Did you try looking at the test cases for docstrings? That's probably the best way ...

Oh you're totally right! What an oversight 😅

One, that certainly shouldn't happen regardless of the platform and sounds like a bug. And two, is it I/O operation on closed file errors?

It occured while Blackening with pre-commit for the first time (but does reproduce with it now too). It's an access denied on semlock.__enter__() leading to a bunch of process terminations. Seems like it's worth another bug report once I narrow it down a bit.

@felix-hilden
Copy link
Collaborator Author

Sorry about the force noise 😅 I got a bit carried away with small details.

I squashed the changes into the two commits, so you can choose if you'd like to separate the commits in master or not, up to you! And the docstring paragraph became a lot longer, so I think it looks nice where it is.

@ichard26 ichard26 self-requested a review April 22, 2021 17:04
@felix-hilden
Copy link
Collaborator Author

Heya once more! With the closing of #1740, I added its style description to this PR, and added a missing test to validate that completely empty docstrings get the space inserted too.

Ready if you are!

@JelleZijlstra JelleZijlstra merged commit 368f043 into psf:master Apr 22, 2021
@JelleZijlstra
Copy link
Collaborator

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
skip news Pull requests that don't need a changelog entry. T: documentation Improvements to the docs (e.g. new topic, correction, etc)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants