Bug: Strings in Excel number fomat do not preserve case(fixes #6317) #63124
Conversation
pandas/io/formats/css.py
Outdated
| in_string = False | ||
|
|
||
| for ch in value: | ||
| if ch == '"': |
There was a problem hiding this comment.
I believe this is not reliable, quotes can also be single quotes no?
There was a problem hiding this comment.
Made the changes as requested. Although I don't think excel supports single-quoted literals in number formats.
| # TODO: don't lowercase case sensitive parts of values (strings) | ||
| val = val.strip().lower() | ||
| if prop == "number-format": | ||
| val = _normalize_number_format_value(val) | ||
| else: | ||
| val = val.strip().lower() |
There was a problem hiding this comment.
One question I have is why are we doing .lower() at all? What breaks if we remove this?
There was a problem hiding this comment.
We lowercase CSS properties and values because CSS is defined as case-insensitive for all keywords and the entire Styler formatting engine is built on that assumption. If we remove .lower(), we immediately break core parts of the parser because the implementation expects all tokens to be normalized before comparison. Everything from font weights, border styles, colors and unit names is matched against internal tables that contain only lowercase entries. Without .lower(), inputs like "BOLD", "SOLID", "Red", "PX", "None", or "THIN" stop matching and fall through the logic.
2 participants
This PR fixes incorrect lowercasing of Excel number-format string literals during CSS parsing and atomization. Pandas previously lowercased all CSS values, which corrupted custom number formats (e.g., "M" → "m").
The fix treats number-format as a special case in both parse() and atomize(), preserving user-provided casing. Additional unit tests verify this behavior and ensure compatibility with existing CSS resolution behavior
doc/source/whatsnew/vX.X.X.rstfile if fixing a bug or adding a new feature.AGENTS.md.