-
-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
[🚀 Feature]: Consistent docstring format for python bindings (Google vs reST) #11442
Comments
also in the examples above as we add more and more types, types are inferred correctly and there is no need to document them explicitly in the docstrings. |
https://github.com/dadadel/pyment/ is a potential option to automate the process, tho it's not something I have used before - edit: not very well maintained as of recently it would appear |
I second this. Also, as a motivation, when using mixed docstring formats in IDEs like PyCharm Intellisense can get confused and I noticed it failed to read parameter specifications for methods using the deviating style. |
This issue is stale because it has been open 280 days with no activity. Remove stale label or comment or this will be closed in 14 days. |
@symonk / @AutomatedTester did we decide what we want to do for this? Do we still have a mix of these in our repo? |
This issue is stale because it has been open 280 days with no activity. Remove stale label or comment or this will be closed in 14 days. |
Any update on this? |
Feature and motivation
Right now across the code base there are docstrings in different formats. A mix of:
Google
style, i.e:and
reST
style:I personally prefer the restructured text versions myself, but I prefer consistency across the board of anything, any preference? Ideally we should have a linter of some sort (be it a tox recipe) that enforces new docstrings are adhering to this. I think it would be useful for building out a modern docs page in future with something like
mkdocs
&mkdocstrings
.There might even be a tool that is smart enough to parse our files and convert each of the above to the other types, I had a look and a few tools exist but seem to be in their infancy.
Opening this ticket so we can decide exactly what type we want to apply throughout collectively. Thanks
Usage example
N/A
I see this as a phase-1 in replacing our existing python API docs (they are very old and don't look particular nice). Once we have consistent style here we can look at auto generating a modern site with mkdocs (not to be confused with
selenium.dev
- this is more of an API reference for python specifics)The text was updated successfully, but these errors were encountered: