Make Quantity and Time/TimeDelta consistent attribute naming - #767

I'm OK with changing Time to be consistent with Quantity.

With Time you can (and should) do almost everything you need without val, vals or isscalar. So I'd vote to put this off to 0.3 and then just go through one release where the former names are available but give a deprecation warning.

Alright, that plan sounds good @taldcroft - we'll leave this as 0.3 then.

Encountered this while looking through old issues -- think this should be tagged 0.3.

My suggestion would be to replace self.val with self.value, drop self.vals, and replace self._time.vals with self._time.value,

+1 to unnecessarily abbreviated attribute names

@mhvk - your suggestion is fine with me. I don't remember the original motivation for providing the always-vectorized version self.vals, but I can't think of anything really strong now so I think it's OK to remove.

We need to have a deprecation release (0.3) for self.val and self.vals. Since self.time._vals is internal that can just happen.

@eteq - I make a quick branch [1] that does the name changes in Time (and even corrects a bug in the process, that Time(single-datetime).value did not work). Could you attach it to this issue? (I cannot do that myself)

[1] https://github.com/mhvk/astropy/tree/time-val-to-value

@mhvk - your branch is now attached.

In the future, it's also fine (perhaps even preferred?) to just create a new PR. As long as one of the commit messages says closes #767, merging it will automatically close this issue.

As for the content of the PR, @mhvk, it looks fine to me except for the tweaks I've issued to your branch in mhvk#3 which change __repr__ to match these name changes.

@eteq - thanks! I've merged your PR (yikes! that I missed so many...). also good to learn about the closes #... method.

np - @taldcroft, does this look good to you? looks good to merge to me now.

Merged, thanks @mhvk and @eteq !

Darnit, 5 minutes after merging I had the question of whether CHANGES.rst was updated with the API change here. Looks like not. @mhvk can you do that in a new quickie PR?