DOC: repurpose `Styler` as a general display tool and not an HTML-CSS tool
See original GitHub issuePandas version checks
- I have checked that the issue still exists on the latest versions of the docs on
main
here
Location of the documentation
https://pandas.pydata.org/pandas-docs/dev/user_guide/style.html
Documentation problem
When Styler
was originally designed and released, its aim was to display HTML in a Jupyter Notebook, that could be manipulated and conditionally formatted. The user guide and documentation over the years has therefore focused on the HTML side of things, and the more recent display and general formatting features are seen as extras to suit that environment, and patchwork included in the documentation.
This issue probably targets pandas 2.0 where I am suggesting that the Table Visualization
part of the user guide pushes Styler
as a generalist DataFrame formatter, describing the generic functionality it has, and also expanding the conditional aspects which can now be output to HTML, LaTeX and Excel.
My philosophy with the development I put into Styler
was for it to be;
- First and foremost a formatting tool to display data in any way the user wants, without changing the underlying data, with outputs to String (i.e. CSV), HTML, LaTeX, Excel, and (ultimately) JSON.
- Provide extra conditional formatting features that suit the environment, e.g. HTML-CSS, LaTeX commands, Excel colors, etc.
Any comments welcome, but I think moving forward having a variety of easily accessible, configurable display representations is a great tool for data science.
Comments very welcome.
Suggested fix for documentation
.
Issue Analytics
- State:
- Created a year ago
- Reactions:2
- Comments:5 (5 by maintainers)
Top GitHub Comments
My two cents as a
Styler.to_excel
“power user”, I like the idea of separating theStyler
into a separate package within the pandas environment. I currently have an internal package to export DataFrames to Excel using Styler as a backend, following an extensive set of formatting rules for a consistent design in line with our style guide regardless of DataFrame. I see one benefit of separating the Styler package to be allowing the possible growth a more vibrant Theming and Plugins community.Also, I’ve had to do some overriding of Styler class functions to get certain behavior I need. Some of these bug fixes and enhancements I’ve submitted as pull requests, but since they’re subject to Pandas’ release tempo, I’ve had to maintain a duplicate set of overrides to access these features in between Pandas releases. Having a separate package would allow the features of Styler to advance at its own pace.
Once there is agreement, I’m happy to help with this. I think it should be quite quick. In Ibis I moved several parts to third-party repos, and the only tricky part is defining the API among the components. Which I think in this case it’s trivial, as I guess the styler is mostly using the pandas public API, and pandas itself doesn’t know anything about the styler.