See #16391 for related discussion and issues.

Overall this seems like a great help to me. Hopefully if we have more norms in the future, authors will create a scale and just use this factory. Probably could do this for TwoSlopeNorm.

The need for rebase comes from the deprecation that went into SymLogNorm re: base change, which the decorator obviously can't know about. I think trying to shoehorn the deprecation into the decorator is going to make things waaaay more complicated than needed, and we may just accept to have a fully separate SymLogNorm until the deprecation is resolved, keeping the decorator only for LogNorm for now.

I guess. Or drop the deprecation warning. Based on the conversations, folks were using this qualitatively and might not complain about the base change.

Let's pick one strategy or the other before I actually do the work of rebasing? :)

#16404 is 3.2, so doing away w/ the deprecation should be fine for 3.3?

Are we fine with breaking after just one release?

I think it was broken before the fix so warning we are fixing a bug for one release seems generous. Ie the function didn’t do what it’s docstring said.

OK, rebased. Still needs API changes note re: breakage.
Now there's just one baseline image that changes -- a single colorbar tick that moves by one pixel. Dunno how this plays with #16286.

Can you write the api break note? ;)

I think we still have a todo wrt SymLogNorm's documentation, but thats not really this PR's problem.

Looks like in #16404 you put the note for the addition of the base kwarg in the wrong file, it should have gone to api_changes_3.2.0/behavior.rst, not next_api_changes/behavior.rst (which is now for 3.3). Can you fix that first?

https://github.com/matplotlib/matplotlib/pull/16541/files I moved it in the backport but have not done the v3.2.x -> master merge up yet.

@tacaswell preferred bumping the removal to 3.4 (#17242 (comment)), so re-milestoning this PR accordingly.

I'm going to try and fix-up symlognorm in #16376 - can I suggest that this PR just deals with LogNorm since we know that's mathematically correct at the moment? That way it will provide a good example of how to construct a norm from a scale, and I can handle symlognorm in one PR instead of having to track it over two different PRs.

I'm fine with that, but can you first check that the init signature wrangling (which is basically just there for SymLogNorm) works for you? I'm not sure I want to remove that part and then put it back.

Could you point out the bit of code you're referring to? I'm afraid I'm struggling to understand the new code here.

All the logic relating to init/init_signature is there to handle the fact that the signature of the norm and the scale don't match directly.

Anyone can merge this on the tests passing.

@jklymak is going to be the point of contact with @dstansby on a follow up PR.

@anntzer I need help using the new _make_norm_from_scale. We have FuncScale, so making FuncNorm seems easy enough. However, I can't see how to plug this into _make_norm_from_scale. If I just do

@_make_norm_from_scale(scale.FuncScale)
class FuncNorm(Normalize):
    """All inherited?"""

then
divnorm = colors.FuncNorm(functions=(forward, inverse))
then I get
TypeError: got an unexpected keyword argument 'functions'
despite functions being a kwarg of FuncScale. So, how are we supposed to pass kwargs? You did it two ways in this PR, neither of which are terribly clear.

OK, I figured it out - you need to specify an init(args) function. So for the above

@_make_norm_from_scale(scale.FuncScale,
    init=lambda functions, vmin=None, vmax=None, clip=False: None)
class FuncNorm(Normalize):
    """All inherited?"""

works

Just to be clear: This is because the order of parameters or even their default values is not the same between symlogscale and symlognorm, and there's no way to guess them (I could make assumptions about parameter order, e.g. everything goes before vmin/vmax/clip, but there's no way I could have autoguessed that for symlognorm, linthresh has no default whereas linscale defaults to 1 and base to 10; compare with symlogscale which has no default for any of them). So the solution I found was to just specify the defaults (and order) separately, via init. (If I missed a better solution, I'm all ears :))

In reality it would be nice if the defaults of the scale and the norm could also be made consistent, but I sort of gave up on having any kind of consistency with symlog...

yes, but the way it is now, just doing it all with default doesn't work. init needs to be explicitly used so far as I could figure out. But I don't particularly understand all the signature binding etc.

Yes, init is needed. The way the norm is inited is basically "pretend you call the init function with the parameters passed to the norm constructor, get the bound parameters (i.e. as if the body of init was return locals() instead of pass), and pass them to the scale constructor".

Yeah, I think the docstring for _make_norm_from_scale didn't get updated to reflect that very clearly. It makes it sound like you don't usually need the init, but you really do regardless of whether the kwargs need to be reordered or not.