Is this something we've decided? Because there are lots of places where we don't check for valid kwargs.

If you look at the linked issues it's pretty clearly a good way to shoot oneself in the foot.
If you're worried about implementation complexity I have something nicer coming up but preferably as a separate PR (well, depends on how much stuff you want to review at once); basically I think the scale classes should just always have the same kwargs (base, nonpos, ...) regardless of the axis rather than havingbasex, nonposx, ..., basey, nonposy) and then we can just have normal constructors with normal signatures (def __init__(self, *, base=10, nonpos='mask', ...):) and not do any of this ridiculous dance.
(The only reason there's basex/basey is because you can pass both of them simultaneously tologlog (loglog(..., basex=3, basey=5)) but loglog already needs to figure out what kwargs it passes to what Scale class, so it may as well also normalize the kwargs to the suffixless versions.)
The main complexity causing this to go to a separate PR is just handling the deprecation there...

Breaking user code is not so much an issue as breaking downstream packages. No developper is safe from using the API in an unintended way and writing seemingly sensical code. So as usual with API changes, a deprecation seems useful (similar to how matplotlib would appreciate upstream packages doing the same).

I... don't understand what "sufficiently correct for the user" means. If you look at the linked issues, I am quite confident that there must be users who are currently passing linthresy instead of linthreshy but actuallynot realizing that they made a mistake, and are therefore generating wrong graphs (note that the older of the two issues has been opened for years and probably none of the reviewers who had a quick look at it noticed the typo from a quick review of the code). Which may be sufficiently correct for them in the sense that they can use them and publish them and put them in presentations and whatnot, but are still wrong.
In that sense I consider this PR to be more of a bugfix than an API change.

Let me give an example for "sufficiently correct for the user". Previouslyplt.show(*args, **kwargs) took positional arguments. This let a lot of people to write code likeplt.show(fig). This does not make any sense, but returns the correct and expected output in all cases where there is only one figure in pyplot anyways. There are a lot of packages out there which still have such code in them; but matplotlib did the correct thing, deprecating the use of positional arguments, such that package maintainers have the chance to correct their mistake without any code actually breaking.

As you mentioned, plt.show(fig) did the correct thing even though it should not be called that way. My claim is that when an incorrect keyword argument is passed to SymLogScale, it's most likelynot doing the correct thing, as shown by the bug reports; code that did so is most likelyalready broken (except that it generates wrong output rather than throwing an exception, but the former is worse).

This applies to any keyword argument:

ax.set_yscale('linear', produce_a_nice_plot=True)

Obviously it is possble to use a footgun and shoot in the air rather than in one's foot. Again I would guess more people are shooting in their foot with it rather than in the air.

Let's see if any other devs want to chime in with their opinion?

Maybe I missed it, so what is the drawback of doing the deprecation with a warning as usual? (A warning by itself should already be enough to keep one's feet healthy)

I guess I think that the general idea that folks should not be allowed to inadvertently make incorrect plots is a fine line to make when deciding whether to check kwargs...

But,... 1) I think this scale is terrible, and I'm not convinced 90% of the people who use it (including the folks who wrote the issues) really understand what it does. Ihonestly think we should deprecate the whole thing. I think if something has vanishingly few published examples (are there any in real journals? I'd never let someone put this in a paper I was reviewing or editing),and it is subject to misunderstandings like this is, we should really reconsider its value.
2) If we are going to keep it,linthreshx/y should be positional with no default so that people who are using itneed to understand it. If we did that, then the function would error onlinthresy. (It would also error on the default no-argument, but...)

mostly agree on 1)
on 2) we can make linthresh{x,y} keyword-only but with no default

Mhh, let's deprecate.plot() then. It draws lines between data points, which results in visuals which are scientifically complete garbage.
Or maybe just stop matplotlib development completely, given that each day thousands of students misuse it to draw nonsensical plots.

Back on topic: Just deprecate passing unused kwargs to this, or any function or method you like and everyone is happy. (Use a one-minor-release-cycle if you think it's urgent - no opposition on that from my side)

Mhh, let's deprecate .plot() then. It draws lines between data points, which results in visuals which are scientifically complete garbage.

Given that there are hundreds of thousands of peer-reviewed articles that useplot (or its equivalent in other packages) I don't think the majority of the scientific community agrees that lines connecting data are "complete garbage". I'm not saying symmetric log plots are complete garbage. I'm just saying that I'venever seen a symmetric log plot in a published paper. If there is a domain-specific community that uses it, by all means they should implement it, or whatever scale they see fit. Having the ability to define custom scales is a great functionality. I just don't think every obscure scale should be part ofcore Matplotlib.

@tacaswell You put in a similar API tightening in6357245 without a deprecation period. Would you support doing the same here (see discussion above)? I will defer to your judgment.

We should all take it down a notch, we all want the same thing at the end of the day, just disagree a about what some details along the way are :)

TL; DR : we should do a deprecation cycle here, I'll push some commits.

@ImportanceOfBeingErnest is completely correct that this is an API change and should be documented and go through a deprecation cycle.

@anntzer is also completely correct that I set precedent of making this sort of API change in a patch release (!).

In my judgement@timhoffm and@anntzer are almost almost certainly correct that everyone we will catch with this changeintend to be passing a kwarg we do not ignore, however@ImportanceOfBeingErnest is also correct that there is a chance that there is some library layer which is abusing the current behavior (I could imaging having a dict of kwargs{'linthreshy': 1.5, 'linthreshx': 1.5} which**kw into both xscale and yscale) that we do not want to break without warning.

On balance, I think I made a mistake in6357245 , and although we have not (to my knowledge) had any complaints about it, we should try to do better about not breaking down stream and users without warning.

Technically the same goes for changing the exception type, but I think we should let that one through as there is no reasonable way to do warnings on that (I guess MI of the two exceptions but then how do you tell when you are caught by the 'wrong one'?).

As a side note, these scales have been in from pre 1.0 days (via2e8ce81 in 2007). Log scales in the negative direction make perfect sense (you make it positive, take the log, put the negative backoutside), log has a linear region around 1 (ln(1+x) ~ x) so there is a reasonable place to smoothly go from log scale -> linear scale and using linear in the middle prevents a discontinuity as your data goes through zero if you have symmetric-around-0 multi-scale data. If someone came today and offered a scale like this I would push them to make a stand alone package, but this scale (andplot) are not going anywhere anytime soon.