-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
BUG: fix precision to specify decimal places #13897
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
Conversation
closes GHI13257 Use 'f' as a string conversion type to specify the number of decimals to represent. The 'g' format will instead fall back to the 'e' format causing the unexpected behavior seen in GHI13257. See: https://docs.python.org/3.5/library/stdtypes.html#old-string-formatting
@@ -507,37 +507,37 @@ def test_display_subset(self): | |||
ctx = df.style.format({"a": "{:0.1f}", "b": "{0:.2%}"}, | |||
subset=pd.IndexSlice[0, :])._translate() | |||
expected = '0.1' | |||
precise_11 = '1.123400' # with the default precision |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pls also test changing the precision from default.
Also, add tests with
|
Current coverage is 85.28% (diff: 100%)@@ master #13897 diff @@
==========================================
Files 139 139
Lines 50057 50057
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
- Hits 42692 42691 -1
- Misses 7365 7366 +1
Partials 0 0
|
@drewrey pls add a whatsnew note (bug fix section) |
Changing it to In [1]: "{:f}".format(1)
Out[1]: '1.000000' and instead have that formatted as Could you add a test with an integer and a float column like |
Looking further, it seems like we have a bug in master. m = pd.DataFrame({"a": [1], "b": [1.]})
Ideally |
can you rebase / update? |
can you add a whatnew note in 0.19.2 |
closing, but if you'd like to update, pls do so. |
git diff upstream/master | flake8 --diff
Use 'f' as a string conversion type to specify the number of decimals to
represent. The 'g' format will instead fall back to the 'e' format
causing the unexpected behavior seen in GHI13257.
See: old-string-formatting
Replicated code from the issue, with output:
