Deprecating the trellis rplot module

Original title: rplot.rst needs cleaning up

---

http://pandas.pydata.org/pandas-docs/dev/rplot.html

plot style, dimensions, grids, legend.

[jreback]

@cpcloud doc-man?

[cpcloud]

Sure! Good a time as any to learn this dark corner of pandas :)

[cpcloud]

I'll clean this up, but IMHO I think the rplot functionality should be deprecated in the next major release of pandas (1.0). Nobody really maintains this. The paucity of issues about rplot suggests that this doesn't see much use in the wild either. Just my 2c.

@jtratner @jreback @y-p thoughts?

[jtratner]

rplot is really useful (and I ported it back to an earlier release because I wanted to use it for a project) but it's slow, somewhat visually unappealing, and (at least for me) hard to figure out how to tweak.

What if we split off visualization into a separate library that pandas would keep as a dep (i.e., the plotting module would provide plot() and allied methods)? We could then have a separate set of maintainers take primary responsibility for that module (and be able to more easily bring in the kinds of things that @olgabot, @TomAugspurger and I believe @JanSchulz have worked on on and off).

Alternatively, I get the sense that rplot was trying to bring in some of the concepts that the ggplot port would now cover, so maybe we could bring it in that way.

[jtratner]

or even if we didn't split it off, just give a few people the responsibility for focusing on pandas visualizations and emphasizing making them look good.

[jankatins]

I think it would make sense to split most of the plotting (from pandas and statsmodels) off into two projects (one ggplot-codeing-style like, one matplotlib-coding-style like). There are currently so many (matplotlib-based and otherwise -> JS, d3,...) python plotting libs showing up, it looks like some consolidation would be nice to not waste so much effort...

[jtratner]

Plus right now you can drop in rplot as far back as 0.11 and it'll work, so
already seems like viz isn't strongly tied into pandas internals.

ggplot2 does indeed have very strong support for faceting so if this was available elsewhere rplot is
somewhat redundant.

Anyway, as I said elsewhere, my view is that pandas shouldn't focus on viz if a suitable alternative emerges.
That wasn't the case 2-3 years ago but things may be slowly changing. Viz is certainly important enough
to have it's own space.

[jtratner]

I looked around, there a bunch of libraries at this point, many of which use pandas internally (e.g., seaborn) so I don't really think it makes sense to go start something new. It would be nice to standardize on one or two though.

[jorisvandenbossche]

Coming back to this older thread (as there was a discussion on the docs of it in #8351): I think it is a good time to reconsider the status of the trellis plotting interface in pandas (tools/rplot.py) and the arguments made above:

• as @cpcloud mentions above, nobody really maintains or enhances this. And hasn't changed the last year since that comment (https://github.com/pydata/pandas/commits/master/pandas/tools/rplot.py). While there are some open issues with bugs about this.
• above there was spoken about splitting it off in seperate projects (eg a ggplot-like one). In the meantime, I think, these projects have already emerged, most notably in python-ggplot and seaborn I think (among probably others)

So: would deprecating the trellis rplot interface in pandas make sense?

@orbitfold You are the original author of this I think. What is your opinion on this?
@jtratner @JanSchulz

As proposed by @TomAugspurger in #8351, we could make a doc section showing for each example of the current pandas trellis interface, how to do the equivalent using python-ggplot and/or seaborn for easy transitioning.