-
-
Notifications
You must be signed in to change notification settings - Fork 171
Remove spaces resulting from line continuation in arg type descriptor #676
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
base: main
Are you sure you want to change the base?
Remove spaces resulting from line continuation in arg type descriptor #676
Conversation
| # bound: length of the parameter, plus three (for | ||
| # space-colon-space). | ||
| arg_type = re.sub(rf" {{{N + 3},}}", " ", arg_type_w_whitespace) | ||
| else: |
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.
I may not be following entirely but this seems wrong to me? Can it deal with the formatting below, where arg_name is quite long?
"""
Parameters
----------
very_long_arg_name : type wrapped \
over multiple lines
Description goes here.
"""
Why not just use
re.sub(r"\s{2,}", " ", arg_type_w_whitespace)\s should also be able to deal with non-breaking spaces and such.
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.
I guess that's a question around whether that formatting is correct or not. If you think the continuing line should not be indented to beyond the colon, then we can just replace two or more (or three or more) whitespaces in a row.
Parameters
----------
very_long_arg_name : type wrapped \
over multiple lines
Description goes here.
This is the format I had in mind, but happy to modify it to be more accepting.
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.
I'd prefer a continuation indent that's independent of the preceding parameter name length. Otherwise you are stuck with potentially very small "column width" for the wrapping type description.
I'm guessing that it's also more consistent with other places where \ is used to wrap and have no requirement on the following indent (Bash, Markdown, ...?). So less potential for surprise. \ simply means, ignore the following newline.
It also minimizes friction on renaming.
And nothing's stopping you from doing the formatting you had in mind with that approach.
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.
Right; we must just pick a minimum. We can say "no double spaces allowed in parameter descriptions" (your proposal), and I'm fine with that.
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.
Or, taking your idea of a "minimum" we require that a wrapped type description must at least be indented by 4 additional spaces compared to the description block (or whatever the expected indent in NumPyDoc is). But using regex substitution with \s{2,} seems easier right now?
Closes gh-87