Allow numpy shape functions on ShapedNDArray subclasses

[mhvk]

Partially addresses #8610, though for now only the simplest numpy functions are supported on all ShapedNDArray subclasses (representations, coordinates, and times):

        np.moveaxis, np.rollaxis,
        np.atleast_1d, np.atleast_2d, np.atleast_3d, np.expand_dims,
        np.broadcast_to, np.flip, np.fliplr, np.flipud, np.rot90,
        np.roll, np.delete,

For instance,

t = Time(np.arange(50000, 50005), format='mjd')
np.roll(t, 2)
# <Time object: scale='utc' format='mjd' value=[50003. 50004. 50000. 50001. 50002.]>

EDIT: while testing, noticed that some functions already worked; e.g., np.moveaxis and np.rollaxis (and np.where though it returns an object ndarray).

[mhvk]

Wow, astrobot is good with adding labels! Note that I also moved ShapedLikeNDArray out of misc.py, as I felt it made much more sense to have it in its own module (as it is becoming quite large, and probably could use its own documentation). If need be, I can separate that out.

[mhvk]

Looking at the PR again, I felt one commit made it harder to review than necessary, so I moved that to its own PR (#10425). For this one, the only real change is in ShapedLikeNDArray - the rest is all tests to make sure it actually works. It complements the array-like shape methods provided with support for numpy functions that affect the shape.

One thing to do in follow-up is to properly implement np.where - right now, I kept it as it was, which means it works but just returns an object array.

@eteq, @taldcroft, @astrofrog - review would be most appreciated, it is not as bad as it looks!

[taldcroft]

I gave this a first pass, looks generally good. I don't see any tests of the new methods for Time, so those should be added unless I'm missing something.

[taldcroft]

What about these symbol definitions for back-compatibility? Are there other uses of ShapedLikeNDArray outside astropy core?

[mhvk]

I'm not sure whether it is used outside the core, and even if it was, it would hopefully have been imported from astropy.utils directly, though it is listed in the API at https://docs.astropy.org/en/latest/utils/index.html#id14. Maybe it makes sense to not copy it over for now, and then possibly re-introduce it if it causes any problems?

[mhvk]

But at least I shouldn't leave commented-out code - I've now simply remove it.

[mhvk]

OK, comments addressed! I added more tests using Time - they just mimic what was added in test_representation_methods, but it makes sense to have them for the different sub-packages.

[mhvk]

Note: numpy-dev travis failure is unrelated; see #10432

[taldcroft]

Looks good from my perspective. For the coordinates stuff I have given it a "looks about right" level of review w/r/t tests and basic functionality.

[mhvk]

@taldcroft - thanks! I realized I had not tested SkyCoord and also not added documentation, so decided I should remedy that. The latter is very short, let me know if you want to have a look (last commit).

[adrn]

I didn't take an extremely close look at the tests, but did look closely at the code and text, and this LGTM (modulo one very minor docs suggestion)!

[adrn]

Suggested change

	(The relevant functions have to be explicitly enabled; let us know if a
	(The relevant functions have to be explicitly enabled in the ``astropy`` source code; let us know if a

To clarify that the user doesn't need to enable anything: something has to be changed in the astropy code itself!

[mhvk]

Good idea! I'll do it in all the places where I added this... (and fix the docs build at the same time)

[mhvk]

Thanks, @taldcroft and @adrn for the reviews. Finally got all the documentation tests to pass (really need an .rst checker for emacs...), and since you both signed off on complementary parts, I'll merge.

[pllim]

Does the error I see in #10471 look familiar to you?

[pllim]

Hmm, looks like the tests in TestManipulation were skipped on Windows because they are marked as remote data. That would explain why CI was green and that maybe I am not crazy.