You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Removing documentation from the function and using Attributes: instead somewhat works, but you only get a table in the Class documentation, attributes are not shown in the right ToC, which makes them hard to discover IMHO.
The best approach to @properties, that works well with pydocstyle and darglint seems to be the following:
classAClass:
"""A class."""@propertydefa_prop(self) ->int:
"""Get the a prop. Returns: The a prop of the class. """return1@a_prop.setterdefa_prop(self, a: int) ->None:
pass
The only downside is properties are still listed as functions, not attributes (but this will change, so all good with this), and there is redundancy in the documentation (basically we need to document it twice, one for the description and one for the Returns:. mkdocstrings doesn't show the type if Returns: is not specified, and if the description is not included, pydocstyle complains.
So far the only option seems to be fixing the issue in the upstream darglint tool.
Use cases
No response
Alternatives and workarounds
We tried to use # noqa as suggested in the darglint issue but according to @jakub-toptal it doesn't work:
What's needed?
Right now we are documenting properties as if they were functions (a description and a
Returnsection are both required), but they are clearly not.Google style says properties should be documented as attributes (in the class documentation) but darglint doesn't support this.
Proposed solution
@propertiesare rendered as function (with a special mark for being a property), but this is planned to be improved in the future to be shown as attributes (see Use MkDocs to build the documentation frequenz-channels-python#25 (comment)).Removing documentation from the function and using
Attributes:instead somewhat works, but you only get a table in theClass documentation, attributes are not shown in the right ToC, which makes them hard to discover IMHO.The best approach to
@properties, that works well withpydocstyleanddarglintseems to be the following:The only downside is properties are still listed as functions, not attributes (but this will change, so all good with this), and there is redundancy in the documentation (basically we need to document it twice, one for the description and one for the
Returns:.mkdocstringsdoesn't show the type ifReturns:is not specified, and if the description is not included,pydocstylecomplains.So far the only option seems to be fixing the issue in the upstream
darglinttool.Use cases
No response
Alternatives and workarounds
We tried to use
# noqaas suggested in the darglint issue but according to @jakub-toptal it doesn't work:Before:
After:
Still fails with darglint code: DAR201
Additional context
There is a darglint issue for this, and at some point we might want to give it a shot to improve property handling in darglint: