-
Notifications
You must be signed in to change notification settings - Fork 17
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.
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
Improve @property
documentation
#39
Comments
We will generate the documentation with To produce a decent result, the minimum documentation needed is: class AClass:
"""A class."""
@property
def a_prop(self) -> int:
"""
Returns:
The a prop of the class.
"""
return 1
@a_prop.setter
def a_prop(self, a: int) -> None:
pass (note the It produces this results: (so it's not ideal that it is listed as a function, but it is nicely annotated as a writable property) But
So it basically demands a text besides the So we can explore if we could disable those class AClass:
"""A class."""
@property
def a_prop(self) -> int:
"""Get the a prop.
Returns:
The a prop of the class.
"""
return 1
@a_prop.setter
def a_prop(self, a: int) -> None:
pass |
Given the amount of work that could be involved in making sure all the tools we use work well with one particular way to documenting properties, I'm starting to lean more towards to just drop this issue and bite the bullet. |
Adding the proposed solution to the issue body. |
Doing some tests with @property
def prop(self) -> T:
"""The property.""" And it should work fine, so this might get a lot easier soon. |
Blocking on adopting pydoclint |
What's needed?
Right now we are documenting properties as if they were functions (a description and a
Return
section 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
@properties
are 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 withpydocstyle
anddarglint
seems 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:
.mkdocstrings
doesn't show the type ifReturns:
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: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:
The text was updated successfully, but these errors were encountered: