-
-
Notifications
You must be signed in to change notification settings - Fork 2k
Deprecate InheritDocstring and remove its usage #8881
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
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
ae22a93 to
53ee23c
Compare
|
@pllim - I like this! But just to be sure, with these changes, the |
075ef86 to
ef205b6
Compare
|
Thanks for the sanity checks! |
mhvk
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good now! I'll leave my last comment to your discretion
| >>> class B(A): | ||
| ... def wiggle(self): | ||
| ... pass | ||
| >>> with warnings.catch_warnings(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're up for it, I'd keep the docstring as is, and rather skip doctests. But obviously no big deal
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still prefer to have the doctest run because I don't want it to break before we have the chance to completely remove it. 😄
|
Since this was approved, I'm going to go ahead and merge it. Thanks for the reviews, everyone! |
|
Yay, here's to PRs that simplify! Next, get |
|
My attempt to build CPython from source on Windows wasn't that successful, so I am out. LOL |
|
I wonder if it would be worth removing the implementation of InheritDocstrings and making it an empty class since it’s not needed, which should still maintain backward compatibility? |
@pllim - that itself is worth an issue upstream, I recall you pointed out a few talks that proudly promote how well everything should work on Windows. |
Only if downstream packages using Sphinx>=1.7, right? Is that guaranteed? |
Hmm, I thought I heard that they are moving their issue tracker to GitHub, but I am not seeing it at https://github.com/python/cpython |
Maybe we shouldn't quietly assume, but it would be a fair assumption after a notification about it on |
oh, yes. They agreed to make the move, and this is a prime example then that issues are not get reported as it's burdensome to report to BPO. @Mariatta - do you have an ETA for the transition from BPO to github? |
|
Sorry, no ETA 😥 Some technical details of how the migration should happen are still needed to be decided. At the moment the issue tracker is still at bugs.python.org. |
|
Hello and thanks for the quick response, @Mariatta ! Is CPython even interested in something like this? If not, there is no point going through the issues stage only to be rejected right away. Please advise. Thanks! astropy/astropy/utils/decorators.py Lines 697 to 717 in bc404ff
|
|
Hmm, |
|
Wow, yet a different reason to always try "reporting" upstream! |
|
Well, this bites back for astroquery via a detour through pyvo 😞 I'll work it around easily, but maybe worth sending either an e-mail around on |
|
Ops... posted a notice in mailing list at https://groups.google.com/forum/#!topic/astropy-dev/ICKNTv0O_vA |
Fix #7167
TODO
sphinx>=1.7. Also see Bump sphinx minversion to 1.7 sphinx-astropy#24Excludecatch the warning there.InheritDocstringfromdoctestorAstropyDeprecationWarningintest_inherit_docstrings().