-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
Allow list-like for y
in DataFrame.plot
.
#19699
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@masongallo do you have any time / interest to work on this? |
@TomAugspurger yes I would be happy to help once I get some time, hopefully later this week. Can you give a bit more details on what you would expect to return in your example above (or a similar example where the user supplies multiple y columns)? |
Thanks! I think it should be equivalent to |
Gotcha - this only makes sense if The |
Gotcha - this only makes sense if a and b are on the "same" scale right?
To get a sensible plot, yes, but users are free to do whatever :)
`secondary_y` is for creating a plot with two independent y-axes. Accepting
a list-like for `y` would allow for an arbitrary number of lines all with
the same y axis.
…On Mon, Feb 26, 2018 at 11:29 AM, Mason Gallo ***@***.***> wrote:
Gotcha - this only makes sense if a and b are on the "same" scale right?
The plot method has a secondary_y arg but I'm not sure it makes sense to
use in a general case like this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#19699 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABQHIic1OXLIgvMTc6vIdrxOQ3f6sn6Jks5tYuoNgaJpZM4SFw5J>
.
|
This makes sense to me & I think the usecase is clear. |
In pandas 0.22 and earlier, we passing multiple values for
y
worked by accident. The code clearly assumed thaty
was a scalar, but things usually worked, perhaps with an incidental warning:On master, this will currently raise. I think that we should explicitly support list-likes for
y
.Tagging for 0.23 since I think this should be a blocker.
xref #18695 where we made the change.
The text was updated successfully, but these errors were encountered: