Repository navigation
Consider adding __setitem__ to SkyCoord to allow mutability #6394
Description
From discussions in #6348, the question here is about the opportunities and implications of allowing SkyCoord to be mutable by adding a __setitem__ method. An implementation of __setitem__ for Time can be seen in #6028, and this addresses some of the complications that arise in setting items in an object with non-trivial attributes (e.g. scale for Time or frame). This issue is not mostly about implementation, we can assume that a suitable implementation can be found.
Opportunities include:
- Support table vstack and join
- Support table insert and add rows
- Making SkyCoord be more like normal arrays. In general mutable arrays are obviously rather useful!
- Allowing resize
- Others?
Implications:
- Astropy code needs to be scrubbed to be sure that
__setitem__clears all caches. - Code that really depends on a SkyCoord being immutable? Where can this introduce bugs in code?
Discuss!
Activity
Cadair commentedon Jul 26, 2017
So this would act like a numpy array right, you can't change size, but you can set long and lat (etc) by simple assignement and given a quantity?
Would the implementation of
__setitem__be on frame or in skycoord only?I am generally 👍 on this in theory.
taldcroft commentedon Jul 26, 2017
Adding a
resizewould be a separate question, but this would count as another opportunity enabled by having__setitem__(since there would be no point to resizing without setting).I think it is feasible to only have this be public on
SkyCoordand be private forFrame. Not clear if this is desirable however.Another possible feature we discussed in the context of Table operations would be requiring use of a decorator to specifically enable mutability over a limited context. I'm also not sure that this is desirable or very useful at the end of the day, but who knows.