-
Notifications
You must be signed in to change notification settings - Fork 36
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
Duplicate docstrings between related classes and functions #242
Comments
|
@atravitz you have been doing some excellent doc work lately, is this still an issue? I can't remember if made a decision on this. |
We should also have this resolved by 2.x (if not sooner) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I think we still want to target this change for 2.0 if possible since docs are quite valuable for us. @atravitz do you know if there was more to be done here? |
@atravitz could you provide an update here? |
I'm going to close this issue. Our docs have improved tremendously since it was first opened. There are probably still cases where we could benefit from more duplication of documentation, but we can address those on a more case-by-case basis when they arise. |
Feature description
#235 follows a recurring theme where lack of duplication in the documentation leads to confusion because it's not always clear to users how the documentation of different classes/functions is linked or why. We should explore better ways to share docstrings without actually duplicating (which would increase maintenance costs and the chance of erroneous docstrings if we miss updating one of many places where something is copy-pasted).
Proposed solution
The most obvious solution is to perform runtime inspection and modification of docstrings by modifying the
__doc__
attribute. In case such runtime modification runs into any issues with Sphinx documentation generation, we could instead use a more kludgy but perhaps less fragile solution like direct inclusion using reST'sinclude
directive.Additional context
As long as we are not maintaining the same code/documentation in multiple places, I think duplication in the user-facing documentation is desirable. @atravitz has also indicated that such duplication would alleviate some of her confusion.
The text was updated successfully, but these errors were encountered: