initial HTML rendering for Series

[big-o]

Added to_html() and repr_html() to Series class.

• closes Series do not display HTML repr #5563
• tests added / passed
• passes black pandas
• passes git diff upstream/master -u -- "*.py" | flake8 --diff
• whatsnew entry

[pep8speaks]

Hello @big-o! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2019-10-28 20:38:39 UTC

[jbrockmendel]

should this warn/raise?

[big-o]

Not sure - I just copied this behaviour from DataFrame._repr_html_() for consistency. Happy to change it if preferred, but if we do that then should the DataFrame behaviour also be changed?

[jbrockmendel]

is there a reason this is moved up from below?

[big-o]

Yes - the SeriesFormatter now inherits from TableFormatter, meaning it needs to be declared first.

[jbrockmendel]

Can you add test(s) for this

[WillAyd]

Any chance you took a look at #27228 prior to this? Haven't reviewed in detail yet but just surprised this is a much larger change than that one. May or may not be an issue just curious

[big-o]

Any chance you took a look at #27228 prior to this? Haven't reviewed in detail yet but just surprised this is a much larger change than that one. May or may not be an issue just curious

Yes I can see why - the implementation by @mrocklin is just calling to_frame, then tweaking the HTML representation to look more like a series. This implementation creates a SeriesFormatter which basically does the same thing as a DataFrameFormatter but assumes only one column, and creates different footer information (to mirror the to_string info). I went with this route because it didn't feel right to me to convert the series into a more complex object just to get some HTML rendering.

Edit: This PR also adds in support for to_html, rather than just repr_html.

I'll freely admit that there's a lot of repeated code between the SeriesFormatter and the DataFrameFormatter - I think that if the DataFrameFormatter was refactored into something more generic then most of this duplication could be removed, making the PR a lot smaller. But I only had a few hours to spare on this hence not wanting to make too many changes to existing code, especially on a project I've never done any dev work on before.

The only other difference really is the aesthetics. In my impl, the footer information sits outside of the HTML table rather than within it. It also uses some different formatting to highlight different bits of information:

If you'd rather see the extra refactoring done to reduce the total amount of code then that's probably more effort than I can afford right now, but if you're happy with the current approach then I can do the remaining work needed to fix old/add new unit tests.

Alternatively, if you prefer the appearance of my solution but the smaller footprint of the other PR, then I could modify that PR to use my footer logic instead.

[WillAyd]

The problem with a PR of this size is that it is difficult to review and adds a lot of code duplication. If there is no way to do this without copy / pasting a lot of code, can you alternately just try to implement repr_html first and then we can address the rest in a follow up PR? Seems like that may be an easier path to go down

[big-o]

That's understandable, but I don't think my changes would be much different by implementing just _repr_html_. The bulk of my work is in the SeriesFormatter and HTMLFromatter classes.

If you'd prefer a smaller change to start with, I think #27228 is basically what you'd end up with. If you'd like me to contribute what you see in the screenshots above, I'd say the best way is to branch off #27228 and make some small changes to it. I'd be happy to do this if you agree that's a good way forward?

I should also add that I'm sure it is possible to do the complete piece of work without the code duplication, but I don't have the time or the knowledge of the existing code to do that right now.

[WillAyd]

I'd say the best way is to branch off #27228 and make some small changes to it. I'd be happy to do this if you agree that's a good way forward?

Yea I would suggest that first. It seems to be in line with what the commentary was on that PR was as well, that just that one piece first would make sense instead of tackling all at once

[big-o]

Have submitted a new PR based on this conversation, #29383, to supercede this one.