Long literal types that need a line return are not understood correctly by pydoclint

[jsh9]

Long literal types that need a line return are not understood correctly by pydoclint

[jsh9]

Thanks for sharing this example. Very interesting!

I used this example and stepped through the code. Here is what I found:

• The type hint of c in the function signature is correctly parsed as this string: "Literal['Option 1', 'Option 2', 'Option 3', 'Option 4', 'Option 5', 'Option 6', 'Option 7', 'Option 8', 'Option 9']"
• The type hint of c in the docstring, however, is parsed as this string: "Literal['Option 1', 'Option 2', 'Option 3', 'Option 4', 'Option 5',"

That's the reason why you are seeing DOC105.

Pydoclint uses numpydoc, the official numpy docstring library, to parse numpy-style docstrings. As far as I know, numpydoc is a rule-based parser (as opposed to an AI-based parser).

When you put 'Option 6', 'Option 7', 'Option 9', ] in the 2nd line of the docstring, the parser naturally thinks that it is the description of the argument c rather than a part of the type hint.

I remember you mentioned over here (astral-sh/ruff#458 (comment)) that pydoclint doesn't provide informative error messages.

I think your assessment is correct in all these 3 cases you mentioned. (This one, #37, and #36) All 3 cases share this similarity: the docstring parser gets confused because the docstring doesn't strictly follow the format.

I think it may be infeasible or at least tricky to really provide "on point" error messages in such cases, simply because the intention of the docstring's author is difficult to infer.

[jsh9]

The more I think about these 3 cases you raised, the more I think we need another linter that specializes in checking just the style of numpy docstrings. It can be named "numpydocstyle" 😂

In pydocslint's README, I actually recommend people use both pydoclint and pydocstyle together:

pydoclint/README.md

Lines 27 to 28 in 1a3596f

	Another note: this linter and [pydocstyle](https://github.com/PyCQA/pydocstyle)
	serves complementary purposes. It is recommended that you use both together.

The underlying reason is the same: pydoclint's scope is to compare docstring against function signatures. The narrower the scope, the better a job it can do.

[erwann-met]

I think you are completely right, ideally we want to use ruff (or pydocstyle) for auto formatting and pydoclint for type check.
If those cases cannot be addressed within the scope of pydoclint then so be it.

Honestly the minute pydocstyle rule D410 is fixed we'll switch from flake8/darglint to ruff/pydoclint.
The two other issues are very minor hindrance, I just wanted to let you know!

I would like to thank you on behalf on my coworkers for the amazing work you made on pydoclint in so little time.

[jsh9]

Thank you! I'm glad that my work can be of help to your team.

Btw, you mentioned that pydoclint couldn't ignore certain rules. If you use pydoclint with flake8, you can use # noqa: DOC... to ignore certain rules inline.

Do you think running flake8 + pydoclint will be very slow for your projects? I'm personally happy with flake8's speed, probably because I don't deal with large monolith code bases.

The "native" pydoclint doesn't support inline ignoring, because I thought piggybacking flake8's inline ignore is fine. If it is really necessary, I can consider adding inline ignoring.

[jsh9]

Closing this issue. No action needed.

[jsh9]

(If I closed this issue by accident, please feel free to leave a comment here.)