ENH: Rename ExcelWriter to make clear attributes are not public

Ref: https://github.com/pandas-dev/pandas/issues/43068#issuecomment-900504112

Copying from the comment above:

The documentation of ExcelWriter says: “None of the methods and properties are considered public.”.

It seems this line the documentation would be easy to miss, and it’d be better to make this more clear via the standard naming convention of a single leading underscore.

[Liam3851]

A small DataFrame would show worst case (i.e. almost all overhead). But I suppose it may depend on the connection itself?

I’d think the overhead would actually come from large excel files, if I’m understanding correctly (I may not be). My impression is that instead of ExcelWriter, we’d use df.to_excel with mode=‘a’, repeatedly appending to the same file. In the remote case though, instead of committing the file as one operation via the end of the ExcelWriter, we would now write a file (sending it to S3), then open it for append, requiring reading it back (retrieving it from S3), close the file again (sending it back to S3), etc. You’re basically looking at 2n-1 file transfers to make a workbook of n sheets, and need to transfer O(n^2) bytes of data back and forth. If I write a workbook of 15 sheets of 5 MB each I need to transfer 1.1 GB of data. Of course this is true without the remote too, but the perf cost is clearer if you picture the transfer going across a 100 Mbps WAN.

I don’t believe this is the case. For nonstandard locations, isn’t this just using startrow/startcol? For fancier formatting, see #40231 (comment). Not sure about charts.

You’re absolutely right about startrow/startcol and the addition of styler.to_excel obviating the need for much of the fancier formatting that used to exist. Conditional formatting in the cells is something I use sometimes in case a downstream recipient wants to add to it, but that is definitely a more niche use case and more suited to an external.

[feefladder]

Hmm, I do think it is nice that sheets is a more general form. ODSwriter puts the tables (sheets) together inside the save function, whereas the others just save the .book. So that would be different implementations… Still it sounds nice to have indeed sheets be recreated/updated on everey write_cells. Should be possible I think.