Give ArrayInterface lower priority

[philippjfr]

The ArrayInterface represents the original format for all our charts types, and it's limitations are what made us eventually go down the route of interfaces (via the terrible diversion of NdElement). While it is a fairly straightforward format simply representing the Rows and Columns of your data as an array, it only works if your data is of uniform type. This means that you have to reason about the types of your data to know how HoloViews will store it. Therefore I'd argue it should not be the default datatype, letting us promote the PandasInterface and DictionaryInterface ahead of it. This means that for columnar data you will always be guaranteed to get one of those types on your .data attribute depending on whether you have pandas installed or not.

The only complication in making this change is that our testing machinery seemingly like neither pandas nor the dictionary data output, so wherever we print .data in the tutorials it fails to do the comparison correctly.

[jlstevens]

... The only complication in making this change is that our testing machinery seemingly like neither pandas nor the dictionary data output

Sounds like there is inconsistent stdout for these datastructures! But surprising (and worrying) if true...

[philippjfr]

No the testing infrastructure just does not know how to compare them properly. Can't quite figure out why in the case of dictionaries yet.

[jlstevens]

... so wherever we print .data

Ah ok, from the above I assumed it was when comparing stdout output. Did you just mean when there are data comparison tests?

[jlstevens]

But yes, a cell where you just do element.data at the end, will show the data (print it, showing the representation) and have data tests unlike print(element.data) which is just stdout. That makes sense.

[philippjfr]

I'm going to push for this to be included in v1.10. It's long overdue and have long recommended that users do not access .data directly.

[jlstevens]

I agree this is overdue.