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
Many cuDF methods have very similar docstrings, including when the same method is present between different classes, but we currently reproduce most of those docstrings. This increases maintenance burden and the chances of docstrings going out of date. As we work to consolidate more logic a la #9038 we should also consider using more programmatic approaches to share docstrings between related functions, something that pandas does extensively (this has come up in a few of the PRs that already started on the work in #9038).
The main downside to such an approach is that it incurs import time costs that will potentially make import cudf slower. Before diving too deep into trying any such approach, we should verify that the additional import time is not prohibitively slow. I'm reasonably confident that the additional cost will be negligible at the moment, though, because currently importing cupy and numba and setting up the rmm allocator for these account for >90% of the import time. I suspect that unless and until those import times drop, any docstring-related logic that we inject at import time will have a relatively insignificant effect in comparison.
The text was updated successfully, but these errors were encountered:
This issue has been labeled inactive-90d due to no recent activity in the past 90 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed.
This issue has been labeled inactive-30d due to no recent activity in the past 30 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed. This issue will be labeled inactive-90d if there is no activity in the next 60 days.
Many cuDF methods have very similar docstrings, including when the same method is present between different classes, but we currently reproduce most of those docstrings. This increases maintenance burden and the chances of docstrings going out of date. As we work to consolidate more logic a la #9038 we should also consider using more programmatic approaches to share docstrings between related functions, something that
pandas
does extensively (this has come up in a few of the PRs that already started on the work in #9038).The main downside to such an approach is that it incurs import time costs that will potentially make
import cudf
slower. Before diving too deep into trying any such approach, we should verify that the additional import time is not prohibitively slow. I'm reasonably confident that the additional cost will be negligible at the moment, though, because currently importingcupy
andnumba
and setting up thermm
allocator for these account for >90% of the import time. I suspect that unless and until those import times drop, any docstring-related logic that we inject at import time will have a relatively insignificant effect in comparison.The text was updated successfully, but these errors were encountered: