@Garrett-R, plot does not take x and y as keyword arguments. This works:

python3 -c "import matplotlib.pyplot as plt; plt.plot([0,1], [0,1]); plt.show()"

@blink1073, thanks I must have realized it at the same time, because I just edited my original post. Please see my new comments.

@Garrett-R, the problem with your suggestion is that plot can 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()"

But perhaps the x and y kwargs could just be treated as if they were the first set of args...

With this change your original example works:

diff --git a/lib/matplotlib/axes/_axes.py b/lib/matplotlib/axes/_axes.py
index 940ebdd..7db782f 100644
--- a/lib/matplotlib/axes/_axes.py
+++ b/lib/matplotlib/axes/_axes.py
@@ -1365,6 +1365,12 @@ class Axes(_AxesBase):
             self.cla()
         lines = []

+        if 'y' in kwargs:
+            args = (kwargs.pop('y'),) + args
+
+        if 'x' in kwargs:
+            args = (kwargs.pop('x'),) + args
+
         for line in self._get_lines(*args, **kwargs):
             self.add_line(line)
             lines.append(line)

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 x and y kwargs weren't being looked at.

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.

The plot api 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 x kwarg, but no y it 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).

@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 x before using y would cover your concern.

The fact that I could not immediately look at @Garrett-R's example and see why it would fail is a good indicator...

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:

The fact that I could not immediately look at @Garrett-R
https://github.com/Garrett-R's example and see why it would fail is a
good indicator...

—
Reply to this email directly or view it on GitHub
#4059 (comment)
.

Fair enough. Then, there are two problems: there should be at least one arg given 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 **kwargs construct).

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 Artist constructor.

@WeatherGod I recently dove into the plot arg 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!

Given the reactions from @tacaswell and @WeatherGod, should we close this with no intent to proceed?

Well, we should probably still raise an error if plot() doesn't see any arguments.

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.

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.