The tracker of items needed to do before deprecating DataFrame.to_latex().

  • [x] acceptance of the jinja2 requirement for LaTeX output, since Styler requires jinja2: this is blocker.
  • [x] make Styler functional for all DataFrames (i.e. including non-unique columns, indexes) (#41269).
  • [x] enhance for longtable keyword or other environments (#41866).
  • [x] enhance for caption to allow short and long captions, and allow top/bottom caption placement. (#41659)
  • [x] enhance with ability to style indexes/column headers with styles (e.g bold rows). (#41993)
  • [x] enhance with an escape option for LaTeX characters. (#41619)
  • [ ] enhance .hide_columns with .show_columns alternative (optional) not necessary
  • [x] enhance .hide_columns and .hide_index to have dual function to hide the entire array, or specific items (#41266)
  • [x] make styler reactive to separate sparse columns and index separately (#41512)
  • [x] acceptance of removal of specific kwargs and all formatting keyword args (see below).
  • [ ] validation for column_format to pass tests or just rely on docs/duck typing? not necessary
  • [x] validation for caption to pass tests (#43368) or just remove the validation in favour of duck typing?
  • [x] ability to format index with a formatter #43101
  • [x] separate siunitx for encapsulating headers in curly braces only when necessary #43397
  • [x] index names removal #43346
  • [x] Optionally use multirow / multicol or just blank out cells. #43369 #43382
  • [x] fix bug: label doesnt render if a caption is not given (table and longtable) #43399

Removed Keyword Args

col_space: removed since Styler.to_latex() does not necessarily produce display values of equal length, (this is a console display only arg) sparsify: replaced by alternative kwargs sparse_index and sparse_columns multicolumn, multicolumn_format, multirow: replaced by alternative kwargs multirow_align multicol_align formatters float_format : replaced by the superior df.style.format(...) args

Comment From: ivanovmg

What about backward compatibility? If I understand correctly we would need to delegate DataFrame.to_latex to Styler.to_latex() and issue a FutureWarning. Should this be added to a checklist as well?

Comment From: attack68

What about backward compatibility? If I understand correctly we would need to delegate DataFrame.to_latex to Styler.to_latex() and issue a FutureWarning. Should this be added to a checklist as well?

Don't deprecations by definition warn of failing backwards compatibility in a future version? For 1.x is it enough to just warn that DataFrame methods will not be developed in future and will eventually be removed (or refactored), albeit they remain in place, as is, for those versions?

I'm trying hard to try and avoid the case where the existing keyword signature of DataFrame.to_html and DataFrame.to_latex must be maintained/replicated or squeezed into Stylers format, for the reason that some of them are bad arguments, and subjectively the new format is decoupled (more maintainable) and more flexible, and consistent from format to format (html, excel, latex).

Comment From: jreback

we can straight depreciate DataFrame.to_latex w/o changing the implementation at all

sure if u can totally do everything in styler.to_latex that would be great but it's likely not a big deal to implement things later / drop features if needed

Comment From: rhshadrach

@attack68 - similar to to_html, I would be in favor of keeping DataFrame.to_latex as a wrapper around Styler.to_latex. It sounds like the current arguments on DataFrame.to_latex make this difficult / undesirable; is it preferable to deprecate DataFrame.to_latex args in favor of the Styler signature rather than removing DataFrame.to_latex altogether?

Comment From: attack68

@rhshadrach as far as I can tell this is the current status:

DataFrame.LatexFormatter has not been updated in quite some time, on the other hand Styler.to_latex has the ability to completely replicate all the options available via LatexFormatter plus a great many features besides.

DataFrame.to_latex, keeping its arguments signature and and its tests, can be effectively recoded to utilise Styler.to_latex, with the exception of one feature: relabelling headers, which came under #45288.

I can see one of 3 possible evolutions for DataFrame.to_latex, in pandas 2.0:

1) Keep it, and its arguments signature, as is but recode it to use Styler and eliminate the LatexFormatter. The arguments signature will effectively be frozen since it is not consistent with Styler and any further development would have to be specifically linked to Styler which will be pretty horrible to maintain.

2) Remove all arguments and just output a basic Latex table, effectively Styler.to_latex with no args. Redirect users to use Styler for more control. Easiest to maintain and document.

3) Provide an api which effectively calls the relevant Styler methods in a chain an outputs the more featured Styler.to_latex. No sure the real benefit of adding this syntactic sugar, Why not just do 2) ?

Comment From: rhshadrach

No sure the real benefit of adding this syntactic sugar, Why not just do 2) ?

Like most syntactic sugar, it's convenient. I would also hazard not many users are familiar with the Styler. Having a DataFrame method gives it visibility, where we can point to the Styler in the API docs for users that want more features.

I'm +1 on 3.

Comment From: attack68

closing as completed via #47970