Skip to content

Conversation

@pllim
Copy link
Member

@pllim pllim commented Jun 20, 2019

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.

@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
@mhvk
Copy link
Contributor

mhvk commented Jul 17, 2019

@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
Copy link
Member Author

pllim commented Jul 18, 2019

@mhvk et al. The inheritance seems to work for the two tested cases (which I deleted from the unit tests above).

Case 1

Case 2

@mhvk
Copy link
Contributor

mhvk commented Jul 19, 2019

Thanks for the sanity checks!

Copy link
Contributor

@mhvk mhvk left a 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():
Copy link
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
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
Copy link
Member Author

pllim commented Jul 19, 2019

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
Copy link
Contributor

mhvk commented Jul 19, 2019

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

@pllim
Copy link
Member Author

pllim commented Jul 19, 2019

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

@astrofrog
Copy link
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
Copy link
Member

bsipocz commented Jul 22, 2019

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
Copy link
Member Author

pllim commented Jul 22, 2019

which should still maintain backward compatibility?

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

@pllim
Copy link
Member Author

pllim commented Jul 22, 2019

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
Copy link
Member

bsipocz commented Jul 22, 2019

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
Copy link
Member

bsipocz commented Jul 22, 2019

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

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
Copy link
Member Author

pllim commented Jul 22, 2019

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

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
Copy link
Member Author

pllim commented Jul 22, 2019

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
Copy link
Contributor

mhvk commented Jul 22, 2019

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

@bsipocz
Copy link
Member

bsipocz commented Jul 22, 2019

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
Copy link
Member Author

pllim commented Jul 23, 2019

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