Matplotlib 3.4 introduces a UserWarning with 1a9dacf when attempting to register a color map by the same name twice. So for a lame luser like myself, how am I to know if my colormap name has already been registered? Is there public API to check if a given cmap name exists?
Proposed fix
Presently, I only see this option via "private" API to check this situation
Hopefully I am not missing something obvious. If something exists, it would be nice to enhance the UserWarning by saying "Trying to register the cmap {name!r} which already exists. Please first check presence of cmap by calling cm.cmap_exists(name)"
There's currently no recommended public way to check if a colormap name exists. A better interface to colormaps is on it's way; see #18503.
For now you can only use your workarounds. Note that both versions are slightly different in that the first only checks for the builtlin colormaps, whereas the second would also include additional registered colormaps.
Did you mean to register them color maps multiple times? One issue with having a "register a string with us to mean something" is that if more than one package tries to register the same name the net result can be dependent on import order! e.g. if modules a and b both do mpl.register_cmap('the_best_cmap', ....) then
import b
import a
...
plt.imshow(..., cmap='the_best_cmap')
would do different things! It is even a bit worse than that because Python modules are process global, if other imports imported a and/or b then it might not matter what order you imported things in.
Which is all a long way of saying we put the user warning in to surface exactly this conversation as to if you intended to register a cmap more than once! If so, why? If you find the name is already registered how can you be sure it is your version of the cmap not someone else?
While there is value in being humble about your code, "lame" working code that ... works is better than "ideal code" which does not exist!
Thanks to both of you for your thoughtful and helpful responses. My usage case is long running mod_python instances whereby my custom colormap registration methods could be called multiple times over the lifecycle of the process. I just was not keeping track of if I had already registered the cmap each time it was called. I am fine with closing this, if there's not action to take here with the upcoming new colormap interface changes.
Activity
workaround mpl 3.4 UserWarning for re-registering cmap
timhoffm commented on Apr 2, 2021
There's currently no recommended public way to check if a colormap name exists. A better interface to colormaps is on it's way; see #18503.
For now you can only use your workarounds. Note that both versions are slightly different in that the first only checks for the builtlin colormaps, whereas the second would also include additional registered colormaps.
tacaswell commented on Apr 2, 2021
Did you mean to register them color maps multiple times? One issue with having a "register a string with us to mean something" is that if more than one package tries to register the same name the net result can be dependent on import order! e.g. if modules a and b both do mpl.register_cmap('the_best_cmap', ....) then
and
would do different things! It is even a bit worse than that because Python modules are process global, if other imports imported a and/or b then it might not matter what order you imported things in.
Which is all a long way of saying we put the user warning in to surface exactly this conversation as to if you intended to register a cmap more than once! If so, why? If you find the name is already registered how can you be sure it is your version of the cmap not someone else?
While there is value in being humble about your code, "lame" working code that ... works is better than "ideal code" which does not exist!
akrherz commented on Apr 2, 2021
Thanks to both of you for your thoughtful and helpful responses. My usage case is long running mod_python instances whereby my custom colormap registration methods could be called multiple times over the lifecycle of the process. I just was not keeping track of if I had already registered the cmap each time it was called. I am fine with closing this, if there's not action to take here with the upcoming new colormap interface changes.
tacaswell commented on Apr 2, 2021
You can also do things like
which will make use of the built in LRU cache to ensure that your functions are only ever run once per process even if they are called multiple times.
timhoffm commented on Apr 2, 2021
I'm closing this as we can't help other than with the new colormap registry (#18503), which is under it's way anyway.
Also there are workarounds available for now.