Coordinates subpackage - #471

@astrofrog re: angule_utilities stuff - a lot of this is legacy code that I think we'll want to revamp later anyway, so I haven't adjusted them. I agree with all the things you said, I just don't want to go in and fix stuff we'll remove/re-work anyway. (and I think some of it is addressed in @iguananaut's PR)

Aside from that, I think I've addressed all your comments - I still need to merge in @iguananaut 's stuff, but once I do you should see all the fixes.

@eteq - awesome, thanks for addressing my comments! I've opened an issue in #544 for integrating Quantity into astropy.coordinates. I think we should probably merge this soon after you have integrated @iguananaut's changes, as I it will be easier to focus on improving various aspects in a more atomic way.

I've also added an issue to keep track of the implementation of array support in astropy.coordinates.

@cdeil - actually, I suppose* we should say the standard way to copy is:

c1 = ICRSCoordinates(...)
c2 = ICRSCoordinates(c1)

I think that's functionally equivalent to copy.copy... the potential gotcha is that copy.copy and copy.deepcopy could be different here (because coordinates contain Angle objects), but I think it's irrelevant because coordinates are basically immutable (in which case copy and deepcopy are effectively the same).

So I'll add a quick example that says you should do it the way I've outlined above, but I think copy also works just fine.

I've now merged @iguananaut's PR, aside from one commit (see eteq#7 for more details if you're interested - I think the commit I ignored is ok, but if there is disagreement it can easily be adjusted in a PR against master once this is merged).

I think this integrates all the comments up to this point. Assuming the tests pass, I think it's good to merge.

If no major problems crop up, let's say Sunday night/Monday morning we'll go ahead and merge!

@eteq - it looks like a test is failing on Python 3.1 and 3.2. Once this is fixed, feel free to merge!

I managed to track down the source of the 3.x error. It appears the sys.exc_info behavior is different in python 2.x vs. 3.x (in the latter it doesn't work outside except clauses, while the former uses the most recent exception), and thus the format_exception function @iguananaut added failed in one place. I've worked around this in a way that may not be ideal, as it provides less information in some error cases under py 3.x than 2.x, but the tests are now passing.

While Travis reports the last two commits here as having failed, that's a bug in travis - the changes in @64c556c fixed it, but the travis build seemed to be one build behind there (the tracebook shows code from the previous commit), while @29fe07b has all the tests actually passing, but Travis hung on one of the egg_info builds due probably to some network problem that has nothing to do with astropy.

@iguananaut - you may want to look into this further (the changes I made in @64c556c) and implement a better fix - I'm not entirely sure what you intended with that function so I didn't want to change it drastically. I'll continue with the plan of merging this tomorrow, and you can do another PR if you get to it in time, or if not you can just work directly in master after this is merged - that should only affect the format_exception function which is used nowhere else so far.

I'm going to go ahead and merge this now (as I said above, the failure in the last commit is not a code failure, but a temporary glitch in travis).

Thanks to @adrn @demitri and @iguananaut for your code contributions. And thanks to @astrofrog @cdeil @taldcroft and @wkerzendorf for your valuable feedback!

Yay, congrats! \o/ Excellent work @eteq, @adrn, and @demitri for the implementation.

Woo! With this in I think we can move toward a RC maybe by the end of this week; though I need to double check what else is still open. It's fine if there are still a few small unsettled issues.

And that's annoying about the sys.exc_info() thing, though I have some vague recollection of a discussion of why they did that. Your workaround seems fine for now; I'll see if I can come up with something better later.

@iguananaut - we should definitely have an RC before the end of the world! (21 Dec) ;-)