Skip to content

Deprecate InheritDocstring and remove its usage - #8881

Merged
pllim merged 3 commits into
astropy:masterfrom
pllim:depre-inherit-docstring
Jul 19, 2019
Merged

pllim merged 3 commits into
astropy:masterfrom
pllim:depre-inherit-docstring

Conversation

@pllim

@pllim pllim commented Jun 20, 2019 •

Copy link
Copy Markdown
Member

Fix #7167

TODO

  • Check doc build and compare with existing doc. Are property and method both inheriting properly?
  • Pin sphinx>=1.7. Also see Bump sphinx minversion to 1.7 sphinx-astropy#24
  • Add change log.
  • Exclude InheritDocstring from doctest or catch the warning there.
  • Catch AstropyDeprecationWarning in test_inherit_docstrings().

@pllim

This comment has been minimized.

Comment thread astropy/utils/tests/test_misc.py
Comment thread astropy/utils/misc.py
@bsipocz

This comment has been minimized.

@pllim
pllim force-pushed the depre-inherit-docstring branch from ae22a93 to 53ee23c Compare July 17, 2019 21:36
Comment thread astropy/constants/constant.py
Comment thread astropy/io/votable/tree.py Outdated
Comment thread astropy/timeseries/binned.py Outdated
Comment thread astropy/units/core.py Outdated
Comment thread astropy/units/tests/test_quantity.py
Comment thread astropy/utils/misc.py
Comment thread astropy/utils/tests/test_misc.py
Comment thread astropy/visualization/interval.py Outdated
@mhvk

mhvk commented Jul 17, 2019

Copy link
Copy Markdown
Contributor

@pllim - I like this! But just to be sure, with these changes, the sphinx documentation will look the same, and if someone tries to get interactive help, that still works too, right? (From a quick check, it looks like ipython is smart enough, and help works too.)

@pllim

pllim commented Jul 18, 2019 •

Copy link
Copy Markdown
Member Author

@mhvk

mhvk commented Jul 19, 2019

Copy link
Copy Markdown
Contributor

Thanks for the sanity checks!

@mhvk mhvk left a comment

Copy link
Copy Markdown
Contributor

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

Comment thread astropy/utils/misc.py
>>> class B(A):
... def wiggle(self):
... pass
>>> with warnings.catch_warnings():

Copy link
Copy Markdown
Contributor

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

Copy link
Copy Markdown
Member Author

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. 😄

@pllim

pllim commented Jul 19, 2019 •

Copy link
Copy Markdown
Member Author

Since this was approved, I'm going to go ahead and merge it. Thanks for the reviews, everyone!

@pllim
pllim merged commit fdb0330 into astropy:master Jul 19, 2019
@pllim
pllim deleted the depre-inherit-docstring branch July 19, 2019 16:55
@mhvk

mhvk commented Jul 19, 2019

Copy link
Copy Markdown
Contributor

Yay, here's to PRs that simplify! Next, get lazyproperty in the standard library?

@pllim

pllim commented Jul 19, 2019

Copy link
Copy Markdown
Member Author

My attempt to build CPython from source on Windows wasn't that successful, so I am out. LOL

@astrofrog

Copy link
Copy Markdown
Member

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?

@bsipocz

bsipocz commented Jul 22, 2019

Copy link
Copy Markdown
Member

My attempt to build CPython from source on Windows wasn't that successful, so I am out. LOL

@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.

@pllim

pllim commented Jul 22, 2019

Copy link
Copy Markdown
Member Author

which should still maintain backward compatibility?

Only if downstream packages using Sphinx>=1.7, right? Is that guaranteed?

@pllim

pllim commented Jul 22, 2019

Copy link
Copy Markdown
Member Author

issue upstream (at CPython)

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

@bsipocz

bsipocz commented Jul 22, 2019

Copy link
Copy Markdown
Member

Only if downstream packages using Sphinx>=1.7, right? Is that guaranteed?

Maybe we shouldn't quietly assume, but it would be a fair assumption after a notification about it on astropy-dev etc, 1.7 is quite old and not see a clear reason why should one limit the version of a devtool that much.

@bsipocz

bsipocz commented Jul 22, 2019

Copy link
Copy Markdown
Member

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

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?

@Mariatta

Copy link
Copy Markdown

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.

@pllim

pllim commented Jul 22, 2019

Copy link
Copy Markdown
Member Author

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!

class lazyproperty(property):
"""
Works similarly to property(), but computes the value only once.
This essentially memorizes the value of the property by storing the result
of its computation in the ``__dict__`` of the object instance. This is
useful for computing the value of some property that should otherwise be
invariant. For example::
>>> class LazyTest:
... @lazyproperty
... def complicated_property(self):
... print('Computing the value for complicated_property...')
... return 42
...
>>> lt = LazyTest()
>>> lt.complicated_property
Computing the value for complicated_property...
42
>>> lt.complicated_property
42

@Mariatta

Copy link
Copy Markdown

Hmm, lazyproperty sounds a lot like cached_property, which is new in Python 3.8 https://docs.python.org/3.8/library/functools.html?highlight=cached_property#functools.cached_property

@pllim

pllim commented Jul 22, 2019 •

Copy link
Copy Markdown
Member Author

Ooooo, it does indeed, @Mariatta . I will move this to a new Astropy issue so we can discuss this properly. I like it when problems solve themselves over time. 😄

See #9036

@mhvk

mhvk commented Jul 22, 2019

Copy link
Copy Markdown
Contributor

Wow, yet a different reason to always try "reporting" upstream!

@bsipocz

bsipocz commented Jul 22, 2019 •

Copy link
Copy Markdown
Member

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 astropy-dev or automated issues to downstream users of InheritedDocstring.

@pllim

pllim commented Jul 23, 2019

Copy link
Copy Markdown
Member Author

Ops... posted a notice in mailing list at https://groups.google.com/forum/#!topic/astropy-dev/ICKNTv0O_vA

@mhvk mhvk mentioned this pull request Jul 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Deprecate InheritDocstrings

6 participants