These are chat archives for astropy/astropy
So you said:
the fundamental issue here is that users should now no longer instantiate frames with data (correct?) and should use SkyCoord instead
ci = ICRS(ra=foo, dec=bar) cfk4 = ci.transform_to(FK4(obstime='J1983’) cfk4.transform_to(Galactic)
ci = SkyCoords(...) cfk4 = ci.transform_to(FK4(obstime='J1983’) cfk4.transform_to(Galactic)
SkyCoord, too, but it’s subtly different
FK4… so maybe a bad example :wink:
SgrCoordinates.distance_from_sgr_dwarf(), you couldn’t do that with
SkyCoordsupports it and the frames used to
SkyCoordis there for those who want to do it faster or are afraid of OO
unitmakes writing a frame class initializer a lot harder, which was one of the main reasons for APE5. So we have to get rid of it at some point
unitin the frames?
c = SkyCoord(’13:14:15’, ‘12d43m98s’, unit=(u.degree,u.degree), system=’sgrcoordinates’) c.distance_from_sgr_dwarf()
Here’s where I am right now, I think: Users need to see the frames to write code that makes good use of the frame specification, E.g.,
fr =FK5(equinox=‘J1987’) ... skycoord.transform_to(fr)
So that calls for them being top-level, if possible. But implementing a class method the way you described is problematic right now, because I think it will require a lot of work to change this, and it is a major departure from APE5.
So the question is how (if?) we want to catch the case of users doing
c = ICRS('13d13m13s', '14h14m14s’)
SkyCoord, presumably those who don’t know any better will learn it that way?
unitsis present, it yields a
SkyCoordand shows a deprecation warning.
c = ICRS('13d13m13s', '14h14m14s’)works but
c = ICRS('13:13:13', '14:14:14’, unit=...)no longer does, and will likely report it as a bug. But if you're ok with dealing with those users than maybe we can keep it as-is. In the end, the 'ideal' solution IMHO is re-implementing the
__init__, which leans heavily on the low-level frames for initialization
SkyCoord.coordobjproperties are confusingly named. That should be cleaned up.