Repository navigation
List of missing arguments not displayed in D417 Missing argument description error #14
Description
When I get D417 errors the list of missing argument is not displayed in the error message.
It would be much more convenient to have the list of missing argument displayed in the error message.
Looking at the code this list get generated here
but does not end up being displayed in the final error message.
example:
def f(a: str, b: str) -> None:
"""
Simple function
Arguments:
---------
a: some argument
"""
print(a+b)
yields
D417 Missing argument descriptions in the docstring
while I would like to get
D417 Missing argument descriptions in the docstring for argument b
Activity
martinResearch commentedon Mar 11, 2022
actually it seems to be working when using directly pydocstyle, but not when done through flake8 so it seems like it is a flake8 problem instead.
sigmavirus24 commentedon Mar 11, 2022
Interesting. This should probably be opened against
flake8-docstringsas that has to coalesce a violation to what Flake8 expects. I expect we're relying onmessagethere from https://github.com/PyCQA/pydocstyle/blob/1011866e6ea91a1fbcb4b01520d2a348becc7de1/src/pydocstyle/violations.py#L17 but it might not be doing the right thing (as message would be building everything but unfortunately includes the code which might be why it doesn't use that).sigmavirus24 commentedon Mar 11, 2022
I transferred it
flake8-docstringsfor youasottile commentedon Mar 11, 2022
it looks like
.messageincludes that context but has a different problem -- it adds an extra:in the message after the code (which makes it incompatible withflake8)two ideas there:
pydocstyle's additional message logic (also seems kinda fragile)martinResearch commentedon Mar 17, 2022
I am not sure to understand why option 1 would be fragile. What do you think could break this solution? If flake8 does not handle error messages with ":" then it seems sensible to replace these, at the cost of denaturing some error messages. Alternatively, could flake8 be modified to handle error messages with ":" ?
asottile commentedon Mar 17, 2022
pydocstyle has changed the format twice now looking at the git history of
flake8-docstringsand I see no reason it wouldn;t change againchanging flake8 is kinda out of the question -- a single plugin doing it wrong shouldn't loosen the framework
martinResearch commentedon Mar 17, 2022
"a single plugin doing it wrong" not sure to have enough context to understand why using a ":" in the error message is wrong. Is it wrong independently of flake8's requirements? If so, is it documented anywhere that error messages should not use ":" outside the flake8 context? Or is that wrong only in the sense that it is not supported by flake8 and no other flake8 plug-in do that ? If so, why would that be a negative thing to loosen flake8 requirement ? it seems to me like it would then be an improvement of flake8 to support it, and could potentially benefit other plugins.
asottile commentedon Mar 17, 2022
yes, the documented message format is code then space then message
changing that would break lots of things
s0undt3ch commentedon Sep 23, 2022
If the format is
[code] [message], then that's easy to parse, and message could virtually contain anything, so why restrain it?s0undt3ch commentedon Sep 23, 2022
In my case, pydocstyle reports
While flake8 ...
s0undt3ch commentedon Sep 23, 2022
Ok, so, it's explicitly only using shor_desc .... Why not the message attribute?
In my case, that seems to be the root cause for now showing what arguments are missing
asottile commentedon Sep 23, 2022
@s0undt3ch I appreciate you trying to help but we've already come to that above and have a reason why
messageis problematics0undt3ch commentedon Sep 23, 2022
Is the
:problematic because of programmatically parsing flake8 output?Anyway, don't know the whole code base to better form an opinion/solution.
s0undt3ch commentedon Sep 23, 2022
We should create(yet another) open standard for linter messages 🤣
asottile commentedon Sep 23, 2022
I mean there is flake8's standard which is
CODE ASCII_SPACE MESSAGEthat's why pydocstyle's (.message)CODE COLON SPACE MESSAGEdoes not work -- that's the whole point of the issue