Open attack68 opened 2 years ago
Makes sense to me. I'd also consider moving the styler to a separate project. Moving to another repo should be trivial, and I think it'd allow the new project to evolve faster, not being constrained by pandas development. And also, it'd open the door to have other competing or related projects, making this part of pandas an extension.
+1 for generalizing and spinning off into a dedicated pandas extension (within the pandas-dev Github project).
Yes this might make sense, possible as part of pandas 2.0. I'm afraid I have little experience in the separating package, new repo management side of things, as regards to setting up tests, and workflows etc, so would need dedicated resources as per the pandas dev team here to do all this - might make this a non-starter? Not a lot of people actively involved in Styler.
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.
My two cents as a Styler.to_excel
"power user", I like the idea of separating the Styler
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.
Pandas version checks
main
hereLocation 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 pushesStyler
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;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
.