-
-
Notifications
You must be signed in to change notification settings - Fork 44
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
Properly documenting the return type in the "Returns" section when using google docstring style #137
Comments
Hello! We support this: def test_func():
"""Return an integer.
Returns:
(int): The integer
"""
print("Hello friends!") This is consistent with how parameters are documented, and was the only viable solution to support named items in returns sections, without a configuration option. The plan is to add such a configuration, because I agree this is non-standard and therefore unexpected 🙂 (I'd love that the Google style got revised though!) |
Hi, thanks, that works good for now with the paranthesis 😄 |
Mostly because this pretty much destroys syntax highlighting on github And use the return type within the "Returns" section in parenthesis. It must be with parenthesis to get it properly documented in mkdocs for now, see mkdocstrings/griffe#137
Mostly because this pretty much destroys syntax highlighting on github And use the return type within the "Returns" section in parenthesis. It must be with parenthesis to get it properly documented in mkdocs for now, see mkdocstrings/griffe#137
Mostly because this pretty much destroys syntax highlighting on github And use the return type within the "Returns" section in parenthesis. It must be with parenthesis to get it properly documented in mkdocs for now, see mkdocstrings/griffe#137
Not sure if I should add this here or open another issue, but there's another aspect that isn't correctly parsed following the google style: the return types of class properties. As per sphinx-napoleon example: class ExampleClass:
@property
def readonly_property(self):
"""str: Properties should be documented in their getter method."""
return 'readonly_property' Unfortunately the project I'm helping with the documentation (pyRevit) cannot yet move to type annotations because it must support IronPython 2.7, so this feature would really help us better document the code! |
@sanzoghenzo how should this get rendered? Do you expect a Returns table/list with just the type, and an empty description? |
Thanks for taking the time to review this! I don't have a strong opinion for this; maybe just add it after the I'm not much into style (as long as it's not ugly!), what matters to me is that the info is accessible and readable 😉 |
OK, then I'll reuse what is available, i.e. a dynamically added Returns section at the end of the docstring 🙂 Not the prettiest but you'll have the info rendered! |
Hi,
I noticed that when using the
google
parser for docstrings, it is not possible to properly document the return type of the return value within theReturns
section itself without using type annotations or giving the value an explicit name.Example
Consider the following test function, and generate the documentation for it with the
google
parser:This results in the following:
Additionally, the following warning is generated:
No type or annotation for returned value 'int'
I would however expect the following to be generated:
The workaround to generate the correct layout like in the above screenshot is of course using type annotations, and rewriting it like this:
However, I think it would still be useful having the ability to simply specify the return type in the "Returns" section and getting the same layout as when using type annotations (and not giving the return value a name).
The primary reason I'm asking is because I'm working on a Cython project, and the github source-code viewer is absolutely not a friend of mixing Cython code with type annotations, and displays this mess. Well, thats more of a github problem, but I'd still appreciate if it would be possible to have the correct layout generated without the use of type annotations :)
The text was updated successfully, but these errors were encountered: