DEPR: LatexFormatter in DataFrame.to_latex in favour of Styler

[attack68]

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

• acceptance of the jinja2 requirement for LaTeX output, since Styler requires jinja2: this is blocker.
• make Styler functional for all DataFrames (i.e. including non-unique columns, indexes) (ENH: make Styler compatible with non-unique indexes #41269).
• enhance for longtable keyword or other environments (ENH: add environment, e.g. "longtable", to Styler.to_latex #41866).
• enhance for caption to allow short and long captions, and allow top/bottom caption placement. (ENH: add long and short captions to Styler.to_latex #41659)
• enhance with ability to style indexes/column headers with styles (e.g bold rows). (ENH: Styler.apply(map)_index made compatible with Styler.to_latex #41993)
• enhance with an escape option for LaTeX characters. (REF: type change escape in Styler.format to str to allow "html" and "latex" #41619)
• enhance .hide_columns with .show_columns alternative (optional) not necessary
• enhance .hide_columns and .hide_index to have dual function to hide the entire array, or specific items (API: make hide_columns and hide_index have a consistent signature and function in Styler #41266)
• make styler reactive to separate sparse columns and index separately (ENH: add styler option context for sparsification of columns and index separately #41512)
• 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
• validation for caption to pass tests (CLN: add arg validation for caption  #43368) or just remove the validation in favour of duck typing?
• ability to format index with a formatter ENH: Styler.format_index() to display index values similarly to data-values with format() #43101
• separate siunitx for encapsulating headers in curly braces only when necessary REF: styler.to_latex siunitx changes: render {} only when needed. #43397
• index names removal ENH: kw names to Styler.hide_index #43346
• Optionally use multirow / multicol or just blank out cells. ENH: multirow naive implementation Styler.to_latex part1 #43369 ENH: multicol naive implementation. part2 #43382
• fix bug: label doesnt render if a caption is not given (table and longtable) BUG: no label render in Styler.to_latex if caption 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

[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?

[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).

[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

[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?

[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) ?

[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.

[attack68]

closing as completed via #47970