Rationalize the functions in plotting.py about bokeh

[dengemann]

@pzwang looking from outside I think the plot + kind/type argument is a neat proposal. Btw. this also how Pandas deals with it which would mean reducing API learning costs for users. Cheers, Denis

[pzwang]

Thanks for the input. For scatter plots on Pandas dataframes, being able to map marker type to groups is natural. (For regular tables or Numpy record arrays, it would be columns or fields that we would map to marker type.) But what about varying plot type (e.g. lines, bars, polygons, and scatter) across the same dataset, in one function call? Is that really useful?

Any thoughts @bryevdv?

[dengemann]

But what about varying plot type (e.g. lines, bars, polygons, and scatter) across the same dataset, in one function call? Is that really useful?

If we're not confused by language this is exactly what pandas does. You can pass 'line', 'bar', 'barh' and 'scatter' as arguments to the kind parameter. I think this is quite neat. Also the qplot function seems to implement a similar logic, at least from a bird-eye view.

[pzwang]

I think we're talking about slightly different things. Looking at the docs for DataFrame.plot, I can see what you mean. What I'm asking, however, is when one might actually vary the type procedurally based on column or group. DataFrame.plot does not support that, and I don't think that's very useful anyway. I see what you mean about reducing API learning cost, but if the top-level scatter(), bar(), line(), etc. functions all took the same core set of arguments, then it's roughly equivalent.

One thing that this does impact is that the domain/co-domain mapping for scatter, line, bar, heatmap, etc. are all different, and require different kinds of downsampling and support different kinds of tools & inspectors. I think distinguishing them at the top level, instead of merely having them be a value argument to one single generic function, makes this actually more accessible for users of the API.