Albert Y. Shih

> p.s. Are you sure inheriting from `property` is actually necessary? The `ipython` example I showed does not change when I remove that inheritance. > > EDIT: also no apparent...

> > This looks good, but let me ping @nstarman as well, since we've just had a case where it was much better for an attribute to return its default...

To elaborate further on my third bullet, we currently have: - true properties (e.g., `frame_specific_representation_info`), which return the `property` instance when accessed on the class, but whose values almost never...

I feel like frame attributes are already a lot like properties, so it feels strictly positive to me to make them behave even more like properties, such as returning the...

> > I feel like frame attributes are already a lot like properties, so it feels strictly positive to me to make them behave even more like properties, such as...

> We could less-elegantly hide this in `__init__` and make `obstime` a `property`. Sure, there could be a different implementation. I imagine that mixin classes could get you close, but...

Yup, understood! I just needed the PR to be re-opened before rebasing because I believe you can't re-open a closed PR if the branch has been force-pushed to since it...

If you want to go this route, it should be a dictionary rather than a class. For example: ```python radius_options = { 'IAU': 0.2725076, 'minimum': 0.272281 } try: R_moon =...

Hence the TODO that I wrote: `# TODO: Find somewhere more appropriate to define these constants` The constants are not defined in astropy nor does it make sense to add...

It's not code effort, but rather design effort. These are constants that make sense only for solar eclipses, hence way too specialized to put into astropy. Our existing constants are...