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
As uncovered here, we should be better documenting the docstring standards we have for Python.
In short, our docstring standard as of today is that we use the Google format. Basically, I think we use the standard off-the-shelf standard - except also do not put parameter type hints into docstrings when those are redundant with the method/function signature as already required by mypy.
The text was updated successfully, but these errors were encountered:
Our linter jobs already check for Google-style docstrings via darglint + flake8, so we should standardize to what's already working to auto-generate docs in the SDK.
If we were to start from scratch, I'd prefer Parameters instead of Args for our method parameters but given that we want consistency, changing the SDK to follow Meltano's lead wouldn't make much sense.
but given that we want consistency, changing the SDK to follow Meltano's lead wouldn't make much sense.
I don't understand this @edgarrmondragon. Why not just change both? We know with certainty that either one works with all of the tools we use, and "parameters" is the more accurate.
I don't want to blow this out of proportion, but it's a matter I (probably irrational) feel very strongly about, so if we're going to choose to go with the option that is technically incorrect, I'd want there to be a very good reason for it.
As uncovered here, we should be better documenting the docstring standards we have for Python.
In short, our docstring standard as of today is that we use the Google format. Basically, I think we use the standard off-the-shelf standard - except also do not put parameter type hints into docstrings when those are redundant with the method/function signature as already required by mypy.
The text was updated successfully, but these errors were encountered: