Repository navigation
Plan to make .representation in coordinates less confusing #6591
Description
This is an issue with a plan for resolving the question raised in #6247 - I'm creating it as a new issue (and closing #6247) because it's a more concrete proposal. We (me, @adrn, @astrofrog, @taldcroft) came up with it during the Astropy coordination meeting 2017.
The idea to resolve the concern of the ambiguous name .representation by doing the following:
- Change the
.representationattribute to.representation_type, and have the docs exclusively use that - Have
.representationremain, now but just point to.representation_type(both setter and getter). In a future version we may deprecate it (There's some disagreement on that point, to be resolved later) - Have the SkyCoord and frame object constructors continue to accept the
representationkeyword as they do now for backwards compatibility, but change the documented use to instead usedataandrepresentation_typekeywords, in parallel structure with the above.
Activity
mhvk commentedon Sep 21, 2017
👍 I particularly like the re-use of
data, which is the attribute pointing to the representation data, as the default argument to pass in such data.One question: would
representation_typebe the class or the string describing it? I guess the former still, correct?taldcroft commentedon Sep 21, 2017
No change from the current
representation, as I understand. The point oftype(as opposed to_cls) was to make setting with a string or class seem sensible. Presumably the getter still returns a class.