Repository navigation
plt.plot fails if given x and y kwargs #4059
Description
When I execute the following command:
python3 -c "import matplotlib.pyplot as plt; plt.plot(x=[0,1], y=[0,1]); plt.show()"
it outputs:
Edit: I see my error. I was not supposed to provide the data as keyword arguments. Indeed plt.plot([0,1], [0,1]) works fine.
I don't know anything about how matplotlib works, but perhaps plot should be able to handle this (similar to how pandas.DataFrame.plot can handle this):
import pandas as pd
df = pd.DataFrame([[0,0],[1,1]], columns=['A', 'B'])
df.plot('A', 'B')
df.plot(x='A', y='B')
If that's not desirable, then perhaps it could at least throw an error or give a warning that an unexpected keyword argument was given...
Activity
blink1073 commentedon Feb 1, 2015
@Garrett-R,
plotdoes not takexandyas keyword arguments. This works:python3 -c "import matplotlib.pyplot as plt; plt.plot([0,1], [0,1]); plt.show()"[-]Data not showing up in plot[/-][+]plt.plot fails if given `x` and `y` kwargs[/+]Garrett-R commentedon Feb 1, 2015
@blink1073, thanks I must have realized it at the same time, because I just edited my original post. Please see my new comments.
blink1073 commentedon Feb 1, 2015
@Garrett-R, the problem with your suggestion is that
plotcan take multiple sets of arguments, for example:python3 -c "import matplotlib.pyplot as plt; plt.plot([0,1], [0,1], 'b', [0, .8], [0, 1], 'r'); plt.show()"blink1073 commentedon Feb 1, 2015
But perhaps the
xandykwargs could just be treated as if they were the first set of args...blink1073 commentedon Feb 1, 2015
With this change your original example works:
Garrett-R commentedon Feb 1, 2015
I like it! 👍
I wonder if there's any downsides to that. I know the upside. I spent about an hour trying to debug my code, and had to read the the matplotlib source before realizing the
xandykwargs weren't being looked at.blink1073 commentedon Feb 1, 2015
It could certainly be made more robust, but I agree it is a nice add. I'll let one of the core devs chime in.
tacaswell commentedon Feb 1, 2015
The
plotapi is modeled on the MATLAB api and far too magical, but changing it to simplify it is a non-starter (because it would break too much code) and I am not a huge fan of adding any more magic to it.One concern I have about @blink1073 's patch is that if there is a
xkwarg, but noyit will erroneously convert the x -> y which would be bad.My knee jerk reaction is 👎 , but am open to being convinced other wise.
Also, I don't think any of the docs say that you can pass in the x/y values via kwargs (if there are, please point me to them so they can be removed).
blink1073 commentedon Feb 1, 2015
@tacaswell, that's why I said it needed more clean up. 😄
I don't consider it magic if it is documented and intuitive, which I think this would be. A simple change to check for the presence of
xbefore usingywould cover your concern.blink1073 commentedon Feb 1, 2015
The fact that I could not immediately look at @Garrett-R's example and see why it would fail is a good indicator...
WeatherGod commentedon Feb 1, 2015
I share thomas's concern. I have repeatedly made attempts to refactor that
code, and failed. My failure to fix it is the main source for my imposter
syndrome in this project...
If changes are made here, then where else should it go? scatter()? bar()?
loglog()? What about polar() with kwargs of "r" and "theta"?
Nah, I think the real problem here is that there was no error reported. No
data was supplied! I know I am a huge fan of ensuring that the plotting
functions work with empty inputs, but I wouldn't go so far as working for
non-existent inputs!
-1
On Sun, Feb 1, 2015 at 11:15 AM, Steven Silvester notifications@github.com
wrote:
blink1073 commentedon Feb 1, 2015
Fair enough. Then, there are two problems: there should be at least one
arggiven to these functions, or they should raise an error. The other problem is that there is no handling of invalid kwargs (they're just ignored, a Python-wide problem with the**kwargsconstruct).tacaswell commentedon Feb 1, 2015
It is made extra bad in mpl due to the way that we pass things up (down) the stack so we can not do validation at most levels. I suspect the right place to blow up is in the
Artistconstructor.@WeatherGod I recently dove into the
plotarg parsing code a bit (69decec which has an astoundingly high commit message length / number of lines changed ratio) and there is no shame in getting bogged down/confused by that code!petehuang commentedon Jan 6, 2017
Given the reactions from @tacaswell and @WeatherGod, should we close this with no intent to proceed?
WeatherGod commentedon Jan 6, 2017
Well, we should probably still raise an error if
plot()doesn't see any arguments.efiring commentedon Jan 6, 2017
It might even not be too difficult to handle the no-args case with x and/or y kwargs, bypassing all the logic required to handle the Matlab-style parsing.
anntzer commentedon Jul 1, 2019
This now errors out with "TypeError: plot got an unexpected keyword argument 'x'".
It was argued in #11526 that we should not support keyword arguments in this case, so I'll just close this.