PR Summary

Closes#24951

Certainly needs tests/docs prior to merge, but opening to further the conversation.

This introduces a method to Converters to validate that a given formatter works with with the Converter.

Currently it is implemented as a staticmethod which returns a bool and then matplotlib warns if that bool is false.
One option that I would consider would be to push the warning into the method, which could then suggest the valid types with a more targetted error message.

I chose a method so that more complicated logiccould be used, but so far all instances I have implemented or considered do simpleisinstance checks.
One alternative if this was sufficient would be to make the thing that gets propegated a list (tuple?) of Formatter classes and then do the isinstance check directly rather than calling the method.
This could potentially also have APIs for registering formatters as valid for a given converter (or just be directly mutable as a list).
The cost, though is that you are limited toonly isinstance checks there.
(Of course with the method implementation, individual classes are free to implement such registration APIs, but lacks standardization)

If the converter is not set, it does not get checked.
Default behavior of ConversionInterface (and any subclasses which do not override the method) is to accept any formatter (i.e. return True indiscriminantly).
Thus except where downstream inherits fromDateConverter orStrCategoryConverter it is entirely opt-in to this additional check.
Converters that expect essentially just float values (and should work with many different formatters that are not all enumerated) retain default behavior (internally, the example is DecimalConverter).
It is only a warning, not an error, mostly to ensure that if the list is wrong, you can still do what you want.

One slight wrinkle that is perhaps slightly awkward is that theNullFormatter does need to returnTrue as that occurs during some setup/initialization phases (as well as just the semantics that you should be able to useNullFormatter to disable labels anyway)

@spencerkclark I am particularly interested in your opinion here
Here is the appropriate diff for nc-time-axis that I tested with:

diff --git a/nc_time_axis/__init__.py b/nc_time_axis/__init__.pyindex a5276ad..76c4d74 100644--- a/nc_time_axis/__init__.py+++ b/nc_time_axis/__init__.py@@ -582,6 +582,12 @@ class NetCDFTimeConverter(mdates.DateConverter):          return result+    @staticmethod+    def validate_formatter(formatter):+        return isinstance(formatter, (mticker.NullFormatter,+                                      AutoCFTimeFormatter,+                                      CFTimeFormatter))+  def is_numlike(x):     """

The growing pain here is that without the above change, the NetCDFTimeConverter class fromcftime will warn for thecorrect formatters and not the mpl-default date formatters (that don't work properly).
This is because of themdates.DateConverter inheritance that is not overridden without the above diff. As such, not sure there is any path that doesn't inherit the incorrect behavior without a change in nc-time-axis.

Since this affects downstream with warnings (not direct errors, at least), I would like to consult with at least the likes of Pandas (xarray's converting/formatting support is largely via nc-time-axis, above).
If there are other downstream projects we should consult with, happy to hear more.

I do not (yet) affirmatively test that the warningis issued, though it did fail a test which setsFixedFormatter on a date axis and already ignores a warning against using such withoutFixedLocator.

Questions:

• Is the information sufficient to make determinations?
  • Would a classmethod be better, or is an instance method necessary? (considering all other functionality of ConversionInterface is staticmethod, that is where I started)
• Would list of types be easier to manage, even if it limits flexibility?
• is checking inset_formatter both sufficient and not overzealous?
  • What about if theconverter is changed? should we ensure warning then?
  • What if you want to changeboth, can it be done without either warning or setting to None?

PR Checklist

Documentation and Tests

• Has pytest style unit tests (andpytest passes)
• Documentation is sphinx and numpydoc compliant (the docs shouldbuild without error).
• New plotting related features are documented with examples.

Release Notes

• New features are marked with a.. versionadded:: directive in the docstring and documented indoc/users/next_whats_new/
• API changes are marked with a.. versionchanged:: directive in the docstring and documented indoc/api/next_api_changes/
• Release notes conform with instructions innext_whats_new/README.rst ornext_api_changes/README.rst