(Alternatively, we could make all
these functions use y as label_namer; I don't really care either way.)

I would rather do this, it seems like an oversight that we did not do this for plot and friends originally.

This is easier to review withhttps://github.com/matplotlib/matplotlib/pull/10928/files?w=1 Most of the whitespace change is due to using partial instead of an extra layer of inner function to create the paramterized decorator.

Calling data-replaced functions used to trigger RuntimeError in some
cases of mismatched arguments; they now trigger TypeError similarly to
how normal functions do (test_more_args_than_pos_parameters).

Please document this as an API change.

It seems a good fraction of the simplification comes from usingsignature.bind and not re-implementing functional that core python provides?

The docstring and signature forplot and friends needs to be updated as they are no longer done by the decorator.

Over all 👍 !

The simplications come from

1. don't do the work that signature.bind does
2. move the plot-specific logic to its own implementation rather than attempt to have a single overgeneralized version
3. dropping replace_all_args and simplifying the replace_names logic (either replace this, this, this and this named argument, or replace all of them) to restrict them to what we need them to do

Question: Currently,

plot([1, 2], "foo", data={"foo": "y"})

works as expected but

plot([1, 2], [3, 4], "foo", data={"foo": "y"})

crashes ("unrecognized character f in format string"). This PR makes both forms "work", although I'm tempted to makeneither work instead (I think the shorthand format string should, well, be a shorthand format string). Thoughts?

The data kwarg actually already has its own documentation in the docstring ofplot:

        data : indexable object, optional            An object with labelled data. If given, provide the label names to            plot in *x* and *y*.            .. note::                Technically there's a slight ambiguity in calls where the                second label is a valid *fmt*. `plot('n', 'o', data=obj)`                could be `plt(x, y)` or `plt(y, fmt)`. In such cases,                the former interpretation is chosen, but a warning is issued.                You may suppress the warning by adding an empty format string                `plot('n', 'o', '', data=obj)`.

The same note, without the PS, is present in step; it is not present at all in loglog and friends. While these could be rationalized I think this is out of the scope of this PR.

Added label_namer support for plot and friends. While doing so, moved from using the terribly namedget_label to a private_label_from_arg which checks whether its second argument is a string, and, if not so, defaults to None instead (to share that logic between the general and plot-specific implementations).

Any chances that this will go in soon? Otherwise I propose to preliminary merge#10872 to fix#11389.

rebased

What is the status of this and#10872. Should#10872 go in as a stopgap?

As a side point, after this PR, we may want to consider the possibility of (... being very prudent here :) ...) making _preprocess_data part of the public API (perhaps under a better name, e.g. process_data_kwarg, up to bikeshedding).
This will both allow others to reuse the functionality, and possibly to move out the spectral plotting functions out to their own mpl_toolkit :p (like everyone else they depend on _preprocess data to massage their arguments).

Sold on this in general and on makingpreprocess_data public.

rebased

Sold on this in general and on making preprocess_data public.

I'm a bit hesitant about this._preprocess_data seems still a bit too clever to be released in the wild.

1. I'd rather strip out the signature manipulation and instead simply require that the wrapped function has adata parameter.
2. Also It shouldn't manipulate the docstring. We cannot assume that users would want the data note as we have it now. - Actually I'm not a fan of this for the matplotlib docs as well. Theparameter should appear in theParameters orAdditional Parameters section like any other parameter.

I'd rather strip out the signature manipulation and instead simply require that the wrapped function has a data parameter.

But the inner function actuallydoesn't takedata as parameter.

Also It shouldn't manipulate the docstring. We cannot assume that users would want the data note as we have it now. - Actually I'm not a fan of this for the matplotlib docs as well. The parameter should appear in the Parameters or Additional Parameters section like any other parameter.

This has basically been discussed to death in the other docstring manipulation issues.

In any case this PR is not making the function public; let's keep that discussion for when the PR shows up (if ever).

I'd rather strip out the signature manipulation and instead simply require that the wrapped function has a data parameter.

But the inner function actually doesn't take data as parameter.

Yep, sorry. I was just repeating a thought from long time ago. The above comment was not the full story. Essentially, when stripping off all the fancy manipulation magic of signatures and docstrings, this could be a simple functionx, y = preprocess_data(x, y, data=data). But as you said, let's keep that discussion out of here.

Added a commit to make plot() error out when x/y are passed as kwargs (this silently does nothing currently, xref#12106).

Thanks@anntzer ! Sorry for the slow review on this.