Skip to content
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

Define Dimension formatters for numpy integer types #1009

Merged
merged 1 commit into from Jan 18, 2017
Merged

Conversation

@philippjfr
Copy link
Member

@philippjfr philippjfr commented Dec 10, 2016

As described in #975, widgets do not correctly format integers at the moment. This is easily fixed by defining Dimension.type_formatters for the numpy integer types.

@philippjfr philippjfr requested a review from jlstevens Dec 10, 2016
@jlstevens
Copy link
Contributor

@jlstevens jlstevens commented Dec 10, 2016

Looks good and I a happy to merge once the tests are passing.

The only suggestion I have is to investigate whether there is an easy way to iterate over all numpy integer types - if so, iterating over them would be better than having to list them all explicitly this way.

@philippjfr philippjfr added this to the v1.7.0 milestone Dec 10, 2016
@philippjfr
Copy link
Member Author

@philippjfr philippjfr commented Dec 11, 2016

The only suggestion I have is to investigate whether there is an easy way to iterate over all numpy integer types.

As long as we are treating them all as separate types I prefer to be explicit about it. I do think that rather than specifying it by an actual type it might be more useful to declare that all integer types should respect the formatter. May we should consider whether int and float formatters should also apply to all numpy types where dtype.kind=='i' and dtype.kind=='f' respectively, if no more specific formatter has been set.

@philippjfr
Copy link
Member Author

@philippjfr philippjfr commented Dec 11, 2016

Apparently this has resulted in small changes in the bokeh table tests. Will update.

@philippjfr
Copy link
Member Author

@philippjfr philippjfr commented Jan 4, 2017

@jlstevens Any opinions on my comment above?

@jlstevens
Copy link
Contributor

@jlstevens jlstevens commented Jan 4, 2017

...it might be more useful to declare that all integer types should respect the formatter

I think I agree that this makes sense.

May we should consider whether int and float formatters should also apply to all numpy types where dtype.kind=='i' and dtype.kind=='f' respectively, if no more specific formatter has been set.

Sounds reasonable for scalars...I assume the formatters won't do a good job for arbitrary arrays.

Edit: Note that I am happy to merge if you want to tackle these other ideas later.

@philippjfr philippjfr force-pushed the integer_format branch from ffb9715 to b4032e4 Jan 9, 2017
@philippjfr philippjfr force-pushed the integer_format branch 2 times, most recently from b8aa93a to c20a253 Jan 17, 2017
@philippjfr philippjfr force-pushed the integer_format branch from c20a253 to 3ef3c4a Jan 18, 2017
@philippjfr
Copy link
Member Author

@philippjfr philippjfr commented Jan 18, 2017

Let's go with this for now. Rebuilding test data shortly.

@jlstevens
Copy link
Contributor

@jlstevens jlstevens commented Jan 18, 2017

The pr build passed. Merging.

@jlstevens jlstevens merged commit 4624484 into master Jan 18, 2017
3 of 4 checks passed
3 of 4 checks passed
continuous-integration/travis-ci/push The Travis CI build failed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage increased (+0.002%) to 77.565%
Details
@philippjfr
s3-reference-data-cache Test data is cached.
Details
@philippjfr philippjfr deleted the integer_format branch Jan 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants