New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Give ArrayInterface lower priority #1236

Closed
philippjfr opened this Issue Mar 29, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@philippjfr
Member

philippjfr commented Mar 29, 2017

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.

@philippjfr philippjfr added this to the v2.0 milestone Mar 29, 2017

@jlstevens

This comment has been minimized.

Member

jlstevens commented Mar 30, 2017

... 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

This comment has been minimized.

Member

philippjfr commented Mar 30, 2017

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

This comment has been minimized.

Member

jlstevens commented Mar 30, 2017

... 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

This comment has been minimized.

Member

jlstevens commented Mar 30, 2017

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 philippjfr modified the milestones: v2.0, v1.10 Feb 9, 2018

@philippjfr

This comment has been minimized.

Member

philippjfr commented Feb 9, 2018

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

This comment has been minimized.

Member

jlstevens commented Feb 11, 2018

I agree this is overdue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment