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

Have StringFormatter respect nan_format #14017

Merged
merged 3 commits into from
Aug 14, 2024

Conversation

bryevdv
Copy link
Member

@bryevdv bryevdv commented Aug 9, 2024

@bryevdv
Copy link
Member Author

bryevdv commented Aug 9, 2024

Well, presumably the nan_format test now fails because the output is - rather than NaN in the image... which makes me wonder, should the default nan_format actually be the string "NaN"? Why is it a single dash? I actually think it really should be "NaN" for the default. cc @philippjfr for thoughts

@bryevdv
Copy link
Member Author

bryevdv commented Aug 9, 2024

@mattpap how can I run individual or subsets of BokehJS tests?

@bryevdv
Copy link
Member Author

bryevdv commented Aug 9, 2024

It looks like nan_format got changed in #12098 after a discussion, but in retrospect I think the decision is not ideal. I suppose perhaps we just make StringFormatter display NaN for these values?

Edit: honestly I rather think null_format and nan_format should be distinct as well...

@mattpap
Copy link
Contributor

mattpap commented Aug 9, 2024

how can I run individual or subsets of BokehJS tests?

E.g. node make test -k StringFormatter. The same applies to test:unit and other sub-commands.

@mattpap mattpap added this to the 3.6 milestone Aug 9, 2024
@philippjfr
Copy link
Contributor

Agree with NaN for the default.

@philippjfr
Copy link
Contributor

honestly I rather think null_format and nan_format should be distinct as well...

Yes, that makes sense to me as well.

@bryevdv
Copy link
Member Author

bryevdv commented Aug 9, 2024

Agree with NaN for the default.

@philippjfr Just clarifying, do you mean the new default for just StringFormatter? Or do mean change the existing default for the numeric formatters that currently specify - as well?

@bryevdv
Copy link
Member Author

bryevdv commented Aug 13, 2024

I split out null_format and made the defaults for StringFormatter be "NaN" and "(null)". I left the defaults for the numeric formatters as-is, i.e. "-" for both. This seems like a reasonable compromise that avoids changing existing behavior.

value = this.nan_format
} else if (value == null) {
value = this.null_format
}
Copy link
Member Author

@bryevdv bryevdv Aug 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW I think this is slightly awkward with the other formatters inheriting from StringFormatter, since they also do the same checks and then often call super.doFormat.

That said, things already seem a bit vague here: e.g. is StringFormatter a formatter for string value inputs or a formatter that formats anything, to string values? In seems like a name more likeTextPropertiesFormatter would be more descriptive here.

@bryevdv bryevdv requested a review from mattpap August 13, 2024 18:15
@bryevdv bryevdv merged commit d55ea6a into branch-3.6 Aug 14, 2024
22 checks passed
@bryevdv bryevdv deleted the bv/10414-string-formatter-nan branch August 14, 2024 21:20
Chiemezuo pushed a commit to Chiemezuo/bokeh that referenced this pull request Aug 27, 2024
* Have StrinFormatter respect nan_format

* split off null_format

* update defaults
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] StringFormatter nan_format seems broken
3 participants