Thanks@toddrjen !

To try and make sure feature PRs don't fall through the cracks, we starting to assign champions who are responsible for making sure the review process goes through,@story645 has agreed to champion this PR.

@tacaswell@story645 Great, thank you!

I don't know why the test coverage has dropped, I added new tests that, as far as I can tell, cover the new code paths.

Assuming this is a good approach, the big outstanding issue in my mind is whether this should be used more in the documentation. There are several examples using the old-styleFormatStrFormatter that could be switched to using this approach.

@toddrjen can you please provide some examples here cause I'm struggling a bit in finding 'em in the PR

@story645 One example for thestr approach used in the documentation is:

axs[5].xaxis.set_major_formatter('{x} km')

Which would replace:

frommatplotlibimporttickeraxs[5].xaxis.set_major_formatter(ticker.StrMethodFormatter('{x} km'))

One for the function approach used in the documentation:

axs[3].xaxis.set_major_formatter(lambdax,pos:str(x-5))

Which would replace:

frommatplotlibimporttickeraxs[3].xaxis.set_major_formatter(ticker.FuncFormatter(lambdax,pos:str(x-5)))

In the pr it’s not clear that you need a pos argument to your function or why.

@jklymak Where, exactly, do you think this should be mentioned? Can you comment on the specific lines or blocks where you think this should be changed? In most cases I am just using or following up on the existing description for theFuncFormatter.

@jklymak Where, exactly, do you think this should be mentioned? Can you comment on the specific lines or blocks where you think this should be changed? In most cases I am just using or following up on the existing description for theFuncFormatter.

It needs to be documented somewhere, otherwise how are people to know what a valid callable is?

@jklymak Please see the updated version. I have added more explicit documentation.

I have added a new commit where I modified a bunch of existing examples and tutorials, and the previous documentation, to make better use of the new syntax. These changes may be more controversial so I added them to a separate commit so they would be easier to roll back.

Please take a look and see what you think.

I don't know why the tests are failing. It doesn't appear to be related to my commit but I am not sure.

@story645 All tests are passing now. Is there anything else I need to do or is this ready?

Sorry I still owe you feedback on this, just wanted to note that I'm +1 on this idea since learning that spotify is basically using this sort of thing as theirmotivating example for writing a new charting library.

@story645 All the discussed changes should be implemented. Please take a look. I am still waiting on feedback on a few issues.

Thanks for your patience, been swamped with Passover.@jklymak and@anntzer have your concerns been addressed?

As stated above I'm basically fine with the PR, but don't like one very specific point (direct support for strings) so don't particularly want to approve it with that feature.

@jklymak

Do we want to replaceevery instance ofStrMethodFormatter andFuncFormatter by this idiom? There is some advantage to pointing out the ticker module and the existence of the suite of Formatters.

I didn't replace every instance.examples/ticks_and_spines/tick-formatters.py still explains how to use the existing method.

Hi Todd, thanks for hanging in there! We're aiming to get this into 3.3 (rc out in a week or so).

Giving it some more thought, keeping the current formatter signature seems fine as it's consistent with the docs and what folks will find on stackoverflows. Can revisit in a later PR.

Do you feel it's ready to merge or do you have any additions to make?

Also now thinking the arguments fix should actually be on FuncFormatter since it's not clear why it needs twohttps://matplotlib.org/_modules/matplotlib/ticker.html#FuncFormatter

@story645 If all the tests pass I think it is ready to merge.