Line block tests

[TomNicholas]

I added some unit tests for blocks.Line(), and extended it to also accept a 1D array input for x (the most natural format for use in xarray).

I also tried to clarify the logic for parsing the input, and make it raise more informative errors.

One high-level question - why allow users to input a list of numpy arrays at all? It makes the internal logic more complex and I don't really see what the benefit is. The only time a list of numpy arrays is a more suitable representation of data than a numpy array with an extra dimension is if the length of the array changes over time, but I don't know if that's actually supported by the plotting functions? Also if you do want to support do you want to keep the data internally as a list of arrays? Or is it okay to do what I did here and convert all lists of arrays straight to numpy arrays using np.asanyarray()?

[t-makaro]

+1 to allowing 1D x-data to be passed. This is API breaking through since x, y are no longer accessible by keyword argument. I'm not saying to change that (I believe this is what matplotlib does, and following this convention in other blocks may make it easier to not pass x values), but it'll have to be noted in the changelog.

Yes, I'd like to keep the ability to pass a list of arrays, for the purpose of animating changing line length. Converting the list of arrays with np.asanyarray() is good because if this is a list of arrays of the same length then it will be a 2D array, and if they are not the same length then it is a 1D array with dtype=object, which is easily recognized by the _make_slice() method.

I'll take a deeper look at the logic later, but it looks good.

[t-makaro]

I believe that you'll need to rebase to avoid merge conflicts with #31.

[t-makaro]

A list of non-uniform length arrays will fail this condition.

[TomNicholas]

So I fixed the mistakes you spotted, and tried to add support for ragged arrays (numpy object arrays of arrays of various lengths).

The code produces the right output for every test, but one of the tests fails because a numpy's assert functions can't seem to deal with an array of arrays:

AssertionError: 
E       Arrays are not equal
E       
E       (mismatch 100.0%)
E        x: array([array([1, 2, 3]), array([1, 2, 3, 4])], dtype=object)
E        y: array([array([1, 2, 3]), array([1, 2, 3, 4])], dtype=object)

I've marked that test as xfailing for now, but I'm not sure what to do about this. We could probably just extract the values from the object array to check explicitly, but this weird behaviour might also be an indication that using array's of arrays is an abuse of numpy...

(Also a minor point, I don't think the private attribute of blocks .is_list should be renamed, because they don't store lists at all!)

[t-makaro]

Only a few small changes left.

I don't think the private attribute of blocks .is_list should be renamed, because they don't store lists at all!

A ragged array behaves like a list (without an easy ability to append) but with some extra attributes. I don't think it's a big deal since it is internal, and the information is passed in as a list.

[t-makaro]

Public API is technically animatplot.Animation since animatplot.__init__ imports Animation and this is what the docs list.

[t-makaro]

I think this else is redundant (but not the self._is_list), since if the above error is thrown it doesn't matter.

[t-makaro]

Excellent work. Thank you! Merging!