REF: Proposal: change `DataFrame.to_excel` to output unformatted excel file

[attack68]

Feature Type

• Adding new functionality to pandas

• Changing existing functionality in pandas

• Removing existing functionality in pandas

Problem Description

TLDR;

Please indicate with a +1 if you are happy for the default DataFrame.to_excel to be changed to output an excel file without any bold or bordered style attached.

Description

The current action of DataFrame.to_excel is to produce an excel file with default bold and bordered styles for column and row headers:

df = pd.DataFrame([[1,2],[3,4]], index=["one", "two"], columns=["A", "B"])
df.to_excel("file.xlsx")

A number of issues are attempting to address this:

• ENH: Make ExcelFormatter.header_style a class attribute instead of a property #50336
• Make header_style a Property of ExcelFormatter #22758
• Expose Formatters via API and Improve Documentation #22773
• ENH: Allow to assign/create custom body_style and header_style property to an instance of ExcelFormatter used in method df.to_excel() #52369
• BUG: df.to_excel() makes some default formatting #50991

In a recent PR (#53973) it is proposed to remove the ability to format excel file styles with DataFrame.to_excel and instead document how users can use the Styler.to_excel to create styles excel files.

This has a number of advantages:

• Simplifies the code, since it is effectively a removal and additions of documentation.
• Creates a more consistent Styler.to_excel (which uses DataFrame.to_excel) since an unstyled Styler wont produce this bold bordering by default.
• Encourages users to use a more flexible tool for formatting.

@pandas-dev appreciate input to gain some form of concensus to proceed.
@WillAyd @rhshadrach @mroeschke

Feature Description

Alternative Solutions

Additional Context

[rmhowe425]

Taking this since I'm already doing the work for this PR

[WillAyd]

+1

[rhshadrach]

+1

[mroeschke]

+1 on a deprecation of to_excel from producing a formatted excel file

[rhshadrach]

@mroeschke - would you be opposed to doing this in 3.0 without deprecation? I think to deprecate this, there would need to be a way to silence the warning - e.g. an argument or option added in and then that deprecated in 3.0. Since this can't break any workflow (it's just styling), that doesn't seem worth the effort to me.

[mroeschke]

Sure a 3.0 break sounds good too