ENH: plot only numeric data and raise an exception *before* plotting if there is no numeric data

[cpcloud]

Raise a TypeError alerting the user to the fact that they are trying to plot nonnumeric data, or if there are any numeric data plot those. closes #1818.

[cpcloud]

I think this should raise before plotting anything... @jreback @y-p thoughts? It's annoying for a plot to come up only to discover that it won't work anyway.

[jreback]

@cpcloud I think there is a flag raise_on_error which does this, @changhiskhan put this is a while back...?

[cpcloud]

raise_on_error only gets called after a plot comes up.

[jreback]

oh
thought that was the point of it
ok then

[cpcloud]

raise_on_error is a way to catch an exception and show the message, it was only being called for nonnumeric data, so i essentially just replaced it with a typeerror which i thought was clearer.

[jreback]

ok...so user can still set raise_on_error to False if they know what they are doing I guess

pls add release notes!

[cpcloud]

@jreback @y-p any thoughts here? i could do something like

if isinteractive():
    ioff()
    the_one_true_plotting_function() # catch the error here before drawing
    ion()
draw_if_interactive()

[jreback]

I dont' use this enough to give you an opinion here, but looks reasonable

[cpcloud]

nvm. i can use the currently-unused-method _compute_plot_data to check...

[cpcloud]

i think plotting only numeric data would be a better solution to this problem. have to check if any issues w/ groupby.plot(). will leave open until 0.12, because Series needs to be an NDFrame (it needs the blkmgr method _get_numeric_data)

[jreback]

this ready to merge?

[cpcloud]

not just yet

[jreback]

FYI this could be done by checking the series dtype but prob better off in. 0.12

[cpcloud]

:) that's what i did, but since it's not critical it might be better to wait

[cpcloud]

also that doesn't cover the case of an object array of numbers which means you have to check the whole array for numbers which is linear in the length of the array which is probably not desirable if u want to plot something gigantic although maybe not the worst thing.

[jreback]

actually since u already know the dtype that shouldn't be a problem except in the case of object
where you can just astype in a try except

[cpcloud]

ah good call didn't think of that

[cpcloud]

should i do that and submit? that should work in 0.12 too right? there will still be astype i presume

[jreback]

sure

[cpcloud]

guess that allows Series(['1.1', '1.2']).plot() to work as well. that ok?

[cpcloud]

i could the 'safe' argument to disallow that

[jreback]

maybe should put a warning on trying to plot an object type in general (if it succeeds that is); otherwise it will raise
in general object type is bad

[jreback]

I think object type should warn or raise

[cpcloud]

probably raise to make the user explicitly choose to cast it if they want

[cpcloud]

also raise on error should probably be taken out since that's more of a stop gap than this, although that is an api change

[jreback]

yep raise on object type is prob easiest thing to do

[cpcloud]

fyi...after this merge the raise_on_error argument will be unreachable

[jreback]

then go ahead and take it out and add a note in API

[cpcloud]

@jreback this is ready 2 go after teh travis buildz