You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[MNT]: Not possible to set AutoDateFormatter rcParam to function without deprecation warning #23012
Not clear if it should be possible, but it is possible to use functions instead of format strings so one may think it should be possible to set the rcParam to a function as well. The documentation is a bit vague and do not really encourage changing them, so maybe it is not supposed to be possible.
`.AutoDateFormatter` has a ``.scale`` dictionary that maps tick scales (the
interval in days between one major tick) to format strings; this dictionary
defaults to ::
In [1]: mpl.rcParams['date.autoformatter.year'] = lambda a: str(a)
C:\Users\Oscar\AppData\Local\Temp\ipykernel_9940\331672118.py:1: MatplotlibDeprecationWarning: Support for setting an rcParam that expects a str value to a non-str value is deprecated since 3.5 and support will be removed two minor releases later.
mpl.rcParams['date.autoformatter.year'] = lambda a: str(a)
Not sure. If so, only when setting it at runtime. Obviously, one cannot set a function in config files. But if there is no technical limitation I don’t See a reason why who shouldn’t allow that at run time.
I guess that the example in the documentation actually tells you how it should be done if you want a function. If I recall correctly, I was just trying to test out some things for code coverage and maybe didn't really read the documentation that much in detail, but thought that it should be possible as I probably copied some other test code...
So if the conclusion is to close this as it is OK and the documentation says so, I will not argue. (Possibly one can add a note that the only way to get a function is to do as in the example, now it can, maybe, be interpreted as one way to use a function, not the way).
As long as the function in importable, we can do something like 'function://module.module:function' as we do with backends.
I wouldn't do that unless we have very good reasons. This is a proprietary pattern users would have to learn (reduces the chance that it gets used) and we would have to maintain it.
Let's not take any actions here until users are asking for it.
Traceback (most recent call last):
File "<python-input-1>", line 1, in <module>
mpl.rcParams['date.autoformatter.year'] =lambdaa: str(a)
~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
File ".../lib/matplotlib/__init__.py", line 750, in __setitem__raiseValueError(f"Key {key}: {ve}") fromNoneValueError: Key date.autoformatter.year: Could not convert <function <lambda> at 0x7fd757c7cc20> to str
Activity
jklymak commentedon May 19, 2022
Do we allow functions for any rcParams?
timhoffm commentedon May 19, 2022
Not sure. If so, only when setting it at runtime. Obviously, one cannot set a function in config files. But if there is no technical limitation I don’t See a reason why who shouldn’t allow that at run time.
tacaswell commentedon May 19, 2022
As long as the function in importable, we can do something like
'function://module.module:function'as we do with backends.I suspect our logic when deprecated this was that if you can not express it in the config file, it should not go in rcparams
oscargus commentedon May 20, 2022
I guess that the example in the documentation actually tells you how it should be done if you want a function. If I recall correctly, I was just trying to test out some things for code coverage and maybe didn't really read the documentation that much in detail, but thought that it should be possible as I probably copied some other test code...
So if the conclusion is to close this as it is OK and the documentation says so, I will not argue. (Possibly one can add a note that the only way to get a function is to do as in the example, now it can, maybe, be interpreted as one way to use a function, not the way).
timhoffm commentedon May 22, 2022
I wouldn't do that unless we have very good reasons. This is a proprietary pattern users would have to learn (reduces the chance that it gets used) and we would have to maintain it.
Let's not take any actions here until users are asking for it.
@oscargus feel free to clarify the documentation.
timhoffm commentedon May 22, 2022
Ah, sorry. I'm against parsing functions from Matplotlibrc. It would be ok to modify the validator to support runtime-assignment.
QuLogic commentedon Jun 21, 2025
This is now raising an error instead of warning: