Fix SkyCoord AttributeError when a new frame is created after a SkyCoord has been inited#5021
Conversation
|
I've milestoned it and put it in the changelog for 1.2 on the theory that it gets merged in time. Of course that can be moved if review/travis reveals problems - this is rather a corner case and is unlikely to be encountered too often by users (although it might show up occasionally if a user creates a |
…d not raise an AttributeError
a1ce73e to
be6fc59
Compare
|
And FWIW, this bug has been in since at least 1.0, it has never appeared before because the |
|
+1 to backporting to 1.0.10 |
|
and 👍 to merging! |
|
@eteq - can you move the changelog entry to 1.0.10? |
[ci skip]
|
@astrofrog - Done! |
Fix SkyCoord AttributeError when a new frame is created after a SkyCoord has been inited
includes manual merge for 1.0.x Fix SkyCoord AttributeError when a new frame is created after a SkyCoord has been inited
While working on #5002 I encountered a curious problem. If you do
python setup.py test -P coordinateseverything works just fine. But, if you dopython setup.py test -P coordinates --args="-k spherical_offsets", you get:Tracking the origin (pun intended) of this problem led to realization of a problem with SkyCoord: the
FRAME_ATTR_NAMES_SET()function insky_coordinate.pyis dynamic, meaning it figures out what all the possible frame attributes are when it gets run... But that dynamic list does not get updated on any already-createdSkyCoordobjects. So if you create a new frame dynamically (e.g., the first time anAstrometricFramegets created), it gets added to whatFRAME_ATTR_NAMES_SET()returns, but the existingSkyCoords do not have one of them. Hence the above error.This PR addresses the problem pretty straightforwardly by just letting a SkyCoord stuck in this limbo-like state to just pass through frame attributes as None when necessary, thereby effectively "dodging" the problem. This also adds a regression test that should catch any similar problems that might arise in the future.
cc @astrofrog @taldcroft