Nathaniel Starkman

What if ``Distance`` didn't convert redshifts to meters when initialized with a redshift quantity? This wouldn't completely solve the problem because ``Distance(np.inf, u.m).z`` would still fail, but at least the...

I hope it's not as bad as all that. Looking at https://github.com/astropy/astropy/blob/f9f71e3e170290c3e3beb4dd2385dde8ac1733d4/astropy/coordinates/spectral_quantity.py#L25, I think SpecificTypeQuantities can have many valid physical types.

If we separate them out, how will the spherical Representations work (they have ``distance`` as a ``Distance``) ?

Okey dokey 👍. If ``Distance`` doesn't support staying as a redshift, then we still have the problem of ``Distance(z=inf).z`` breaking.

> Be lenient? E.g. only make the comparison up to float 32 precision? Instead, we could make the comparison based on the precision of the ``dtype``, using something like https://numpy.org/doc/stable/reference/generated/numpy.finfo.html?highlight=finfo#numpy.finfo

Does this keep the numpy dtype of the input?

So ``Latitude(pi/2, unit=u.deg, dtype=float32)`` can become a float64?

No strong opinion. Just minimizing private API. I use MappingProxyType anywhere I want to make an immutable dict linked to a dict I don't want changed. I find it particularly...

@AlexWaygood, I narrowed the source of the problem. It isn't setters and deleters by themselves, but in conjunction with (at least) weakref (and maybe other types).

Just tested on ```python from __future__ import annotations from typing import Generic, Protocol, TypeVar T = TypeVar("T") O = TypeVar("O", covariant=True) class Thing(Protocol[O]): def __call__(self) -> O: ... class Bar(Generic[T]):...