Repository navigation
Plan to make .representation in coordinates less confusing #6591
Description
Activity
👍 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?One question: would representation_type be the class or the string describing it? I guess the former still, correct?
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.
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
.representationby doing the following:.representationattribute to.representation_type, and have the docs exclusively use that.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)representationkeyword as they do now for backwards compatibility, but change the documented use to instead usedataandrepresentation_typekeywords, in parallel structure with the above.