SkyCoord dynamic changes tests and docs PR - #8

Thanks, looks good!

I've only just started! Lots to put in yet. Adding tests for
preferred_representation right now.
On Jun 2, 2014 11:25 PM, "Tom Aldcroft" [email protected] wrote:

Thanks, looks good!

—
Reply to this email directly or view it on GitHub
#8 (comment).

OK, I was just going to ask if you planning more commits.

Does the setter property take string inputs? You've mentioned in a comment:
'allow string input'.
On Jun 2, 2014 11:27 PM, "Tom Aldcroft" [email protected] wrote:

OK, I was just going to ask if you planning more commits.

—
Reply to this email directly or view it on GitHub
#8 (comment).

Okay, passing in a string to the setter is throwing an error, so I'm
assuming string functionality hasn't been implemented yet. I'll put it in.
What kind of strings should be allowed, first of all?
'SphericalRepresentation' is one such example, but to what extent is the
user given leeway to shorten the string?
On Jun 2, 2014 11:36 PM, "Pritish Chakraborty" [email protected]
wrote:

Does the setter property take string inputs? You've mentioned in a
comment: 'allow string input'.
On Jun 2, 2014 11:27 PM, "Tom Aldcroft" [email protected] wrote:

OK, I was just going to ask if you planning more commits.

—
Reply to this email directly or view it on GitHub
#8 (comment).

@vaticancameos - the setting will take a string input like "cartesian" or "spherical". I'm going to add code to do this (not quite like your implementation) so you should just hang on for the moment.

@taldcroft Do let me know what is to be done. I would love to be able to
contribute something of note. What do you have in mind? How can I improve
my implementation?
On Jun 3, 2014 8:05 PM, "Tom Aldcroft" [email protected] wrote:

@vaticancameos https://github.com/VaticanCameos - the setting will take
a string input like "cartesian" or "spherical". I'm going to add code to do
this (not quite like your implementation) so you should just hang on for
the moment.

—
Reply to this email directly or view it on GitHub
#8 (comment).

@vaticancameos - writing tests would be a very valuable contribution. For now you should do the tests using the syntax representation=<RepresentationClass>.

Tests should include:

• Test all permutations of allowed inputs for a single frame like ICRS for SkyCoord:
• With keywords like x=.., y=..: scalar, list, array, quantity values
• With positional arguments (scalar, list, array, quantity)
• Different unit permutations (single unit string, multi-unit string, single unit object, tuple of unit objects)
• Test keyword inputs for every representation of every built-in frame type (i.e. confirm that all the _representations for each built-in frame are complete and correct).
• Test that setting the representation via coord.preferred_representation = CartesianRepresentation gives the same values for x, y, z as coord.cartesian (and so on for other representations).
• Test that setting the representation does not change the underlying .data object.
• Test that spherical attributes ra, dec, distance become unavailable after setting the preferred_representation to CartesianRepresentation.
• Anything else you can think of! Try to break it with some input that you think should work.

I've rebased onto your branch's current state and removed my commit about the preferred representation setter which wasn't needed. Working on tests now.

Okay, this branch is messing up after the rebase. I'll open a new branch and new PR.