Skip to content

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.

Sign up for GitHub

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

Open
stefanv wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Remove spaces resulting from line continuation in arg type descriptor #676

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e6669e4
Remove spaces resulting from line continuation in arg type descriptor
stefanv Jan 21, 2026
41e6c73
Merge branch 'main' into strip-spaces-from-arg-type-continuation
stefanv Jan 21, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 12 additions & 1 deletion numpydoc/docscrape.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -222,12 +222,23 @@ def _read_sections(self):

def _parse_param_list(self, content, single_element_is_type=False):
content = dedent_lines(content)

r = Reader(content)
params = []
while not r.eof():
header = r.read().strip()
if " : " in header:
arg_name, arg_type = header.split(" : ", maxsplit=1)
arg_name, arg_type_w_whitespace = header.split(" : ", maxsplit=1)
N = len(arg_name)

# This strips spaces that arose from
# backslash-continued lines. Unfortunately, we don't
# know the offset of the original docstring, and
# therefore also not the number of spaces introduced
# by the continued line. However, we can set a lower
# 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

@lagru lagru Jan 21, 2026

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

@stefanv stefanv Jan 28, 2026

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

@lagru lagru Jan 28, 2026

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

@stefanv stefanv Jan 28, 2026

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

@lagru lagru Jan 28, 2026

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?

# NOTE: param line with single element should never have a
# a " :" before the description line, so this should probably
Expand Down
14 changes: 14 additions & 0 deletions numpydoc/tests/test_docscrape.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -207,6 +207,20 @@ def test_parameters(doc):
assert desc[0].startswith("The type and size")


def test_type_continuation():
doc = NumpyDocString("""
Parameters
----------
foo : a type that goes across \
multiple lines
This is the description line.
""")
arg, arg_type, desc = doc["Parameters"][0]
assert arg == "foo"
assert arg_type == "a type that goes across multiple lines"
assert desc[0] == "This is the description line."


def test_other_parameters(doc):
assert len(doc["Other Parameters"]) == 1
assert [n for n, _, _ in doc["Other Parameters"]] == ["spam"]
Expand Down