Open Discussion about iplot method

[gjeusel]

I recently came across cufflinks, and as a daily user of pandas & plotly, I've just fallen in love with this idea of linking them together!
Indeed, getting sweet plots quickly with plotly can be a little bit troublesome to my opinion, as there are so many options...
Cufflinks that aims at some kind of standarization for basics plots is just awesome!

What I especially like is the idea about adding a new method iplot to every pandas instance.

Yet, to handle every and each one cases, the function cufflinks.plotlytools._iplot in the code is quite large, and hard to read to my opinion.
So I was thinking: maybe decomposing different plots into methods for pandas.Dataframe.iplot would be of interest to better the code structure? (And also I find it eases the use of it)
What I mean by that:
df.iplot(kind='heatmap') would become df.iplot.heatmap()
df.iplot(kind='scatter') would become df.iplot.heatmap()

And what goes along is an easier handling of all parameters passed to thoses methods.

For the moment, I just put it as optional, and created a jupyter notebook to make my point.

Happy to share about that, cheers

[timkpaine]

.iplot is supposed to match .plot, from here.

[gjeusel]

Wow ! I didn't knew that. But surprise, look at what's written:

New in version 0.17.0: Each plot kind has a corresponding method on the DataFrame.plot accessor: df.plot(kind='line') is equivalent to df.plot.line().

[timkpaine]

So long as they match I don't think anyone will mind.

[jpoles1]

I like the idea, as this will clean up the code, and will also make the documentation in #107 much clearer!

[santosjorge]

Yes the idea was to math the plot method in Pandas. That is where the actual kind keyword came from instead of the common type form in Plotly figures.

It was also meant to be for very quick charting, where arguments are interchangeable across chart types (which is not entirely the case in figures directly) so any user could just change the chart kind on the fly.

However, I agree the code in iplot has grown a bit too much. And with some many kwargs it has become difficult to understand.

I like the idea of having a method for each figure type. It may be challenging in some instances, as it will seem to overlap with native DataFrame methods. For example DataFrame.hist which is Panda's own histogram method.

The iplot method would still remain - and every standalone method would just call iplot with the relevant arguments. Not sure if this wold help massively for code readability, but it will certainly help for documentation purposes.

This would only apply to regular charts, and not to QuantFigure charts.

Let me know what you guys think.

[gjeusel]

Well, I've made a litte POC here on how to structure the code.
Now pandas (0.23.0) offers a pandas.api.extensions.register_dataframe_accessor as a decorator to add new methods.
Any returns ?

[chowyifat]

really need the type of line char with error-band