WIP: REF: DataFrame.to_html directs to Styler.to_html

[attack68]

This is being worked towards in #41693. Please look at that issue and comment if there are specific features we need to keep/discuss. This is a medium term project I've been working on but would be great if someone else in team can be sounding board.

[alimcmaster1]

Seems like some great work is being done here. I'm likely missing something but has anyone else in @pandas-dev/pandas-core approved/+1 this?

As I suspect this might receive some complaints from users for 1.4 since this is such a commonly used method.

[bashtage]

What goal does it serve to have users reach deeper to access a method that has been around for ages?

[jreback]

we could leave this method snd just return the styler inpl of it? (and if there are specific deprecations then do those for unsupported features?)

[jorisvandenbossche]

@attack68 I seem to remember some previous discussion about this, but it's not in the issue you link (#41693). Do you know of older issues that had some of this? (#41693 does summarize some concerns that I suppose came from earlier discussions)

(eg issues like having jinja2 as a requirement for html repr in the notebook, which basically makes jinja2 a semi-required dependency)

EDIT: one such issue might be #11700

[attack68]

What goal does it serve to have users reach deeper to access a method that has been around for ages?

• maintaining only one set of rendering methods and tests to produce HTML output.
• removing some of the deprecated features of DataFrame.to_html that haven't been followed up over the years.
• better performance and more features in Styler.to_html.

@attack68 I seem to remember some previous discussion about this, but it's not in the issue you link (#41693). Do you know of older issues that had some of this? (#41693 does summarize some concerns that I suppose came from earlier discussions) actually #11700

Yes @jorisvandenbossche, in that issue you mentioned two barriers, which have been addressed. You identified same advantages as me, and mentioned disadvantages; the performance is resolved, you can test but I think Styler.to_html(exclude_styles=True) is faster than DataFrame.to_html(), and the jinja2 dependency is a must if this is to progress.

we could leave this method snd just return the styler inpl of it? (and if there are specific deprecations then do those for unsupported features?)

@jreback yes for sure, but as mentioned would need a refactoring of the input arguments, I think.

[jreback]

so i think would be ok to deprecate these scenarios

• no jinja2
• whatever features / kwargs that are not supported ultimately

then we can remove the existing implementation in the future (though keep .to_html is prob ok and just have it call the styler inpl)

[bashtage]

What goal does it serve to have users reach deeper to access a method that has been around for ages?

• maintaining only one set of rendering methods and tests to produce HTML output.
• removing some of the deprecated features of DataFrame.to_html that haven't been followed up over the years.
• better performance and more features in Styler.to_html.

I wan't suggesting keeping 2 implementation. I was just quibbling moving to_html to a different location. I think what @jreback said is the best way forward.

[attack68]

I wan't suggesting keeping 2 implementation. I was just quibbling moving to_html to a different location. I think what @jreback said is the best way forward.

will work towards that, seems sensible and has good support.

[jorisvandenbossche]

However, I think we need to discuss the jinja2 dependency a bit more, first. What does that mean? Do we keep that as an optional dependency as it is right now?
In practice, that would mean that we don't support the html rendering in notebooks by default. IMO, that would be a bad usability regression. One option to solve this is to make jinja2 a required, hard dependency of pandas. But I don't know if that is what others where also thinking.

[attack68]

Personally, I expected that jinja2 would be added as a hard requirement.

Having said that using pandas in a Notebook is commonly used with charting, where matplotlib is an optional dependency, so forcing another optional dependency might not be too restrictive, especially if well documented.

A fallback for a non-jinja2 notebook could be to use the string representation of a DataFrame with/without a warning (although currently it doesnt seem to trim for large dfs)?

[jreback]

so adding jinja2 as a hard requirement for styler is fine i think

[jreback]

ahh just read @jorisvandenbossche comment again

i think we should just add it as a hard requirement

[lithomas1]

Quick question: Would this be targeted for 1.4 or 2.0? I feel like we would need a deprecation cycle before switching the implementations around.

[github-actions]

This pull request is stale because it has been open for thirty days with no activity. Please update or respond to this comment if you're still interested in working on this.

[attack68]

closing this temporarily in favour of #44451