Skip to content

Conversation

@stefanv
Copy link
Contributor

@stefanv stefanv commented Jan 21, 2026

Closes gh-87

# bound: length of the parameter, plus three (for
# space-colon-space).
arg_type = re.sub(rf" {{{N + 3},}}", " ", arg_type_w_whitespace)
else:
Copy link

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.

Copy link
Contributor Author

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.

Copy link

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.

Copy link
Contributor Author

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.

Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Convention for multi-line type specifications

2 participants