Automatic registry in matplotlib on import #161

Activity

1. tlambert03 commented on Oct 16, 2026

   

   tlambert03

   on Oct 16, 2026

   Member

   More actions

   hey, thanks for posting. I'm happy to explore options here. Not immediately sure I'd want it to autoregister the entire catalog as a side effect of importing cmap. I think i'd prefer an explicit function call (that ultraplot or others would be welcome to call). If you have thoughts and want to open a PR, feel free to. Or i will have a look myself soon
2. cvanelteren commented on Oct 16, 2026

   

   cvanelteren

   on Oct 16, 2026

   Author

   More actions

   Registry need not interfere with mpl's default colormaps. The easiest would be to prepend a classifier. It think colormasher, for example, does this with cmr.[colormap] on import.
   I think it it would be easiest if you have a crack at it, since I don't want to presume design decisions here.
3. cvanelteren commented on Oct 16, 2026

   

   cvanelteren

   on Oct 16, 2026

   Author

   More actions

   The setup would need to do this coarsely

   cmap = ListedColormap(colors, name=f"cmr.{name}")
   mpl.colormaps.register(cmap)
   mpl.colormaps.register(cmap.reversed())

   (for all)
4. tlambert03 commented on Oct 20, 2026

   

   tlambert03

   on Oct 20, 2026

   Member

   More actions

   solved by #162
5. tlambert03

   closed this as completedon Oct 20, 2026
6. cvanelteren commented on Oct 21, 2026

   

   cvanelteren

   on Oct 21, 2026

   Author

   More actions

   @tlambert03 can you outline if the proposed fix for auto registration could something we could explore too?
7. tlambert03 commented on Oct 21, 2026

   

   tlambert03

   on Oct 21, 2026

   Member

   More actions

   By we do you mean camp?

   ultraplot could do that directly too right? I think my general feeling is that downstream users all have multiple ways to implement string support in mpl. I really don't want to auto register the full catalog immediately at import time here (it wasn't just about import time as I mentioned in the PR). And if we're not auto registering, then there's no major difference with a downstream library doing their own registration right?

   Was the intention of the lazy colormap to indeed then go back to auto registration?
8. cvanelteren commented on Oct 21, 2026

   

   cvanelteren

   on Oct 21, 2026

   Author

   More actions

   It would create a dependency that need not be there. We could have handled the auto registration on our part without #162. I see the issue with loading the data densely. We approach this through lazy loading and to only deal with it when the actual colormap is being used. My suggestion was that the registration loading time you indicated on #162 could have been mitigated by doing a similar trick. This way auto-registration occurs similar to cmasher, but without the issue of increased loading time.
9. tlambert03 commented on Oct 21, 2026

   

   tlambert03

   on Oct 21, 2026

   Last edited by tlambert03

   Member

   More actions

   Right, but loading time was only one of the reasons I don't want to eagerly register the entire namespace. For me, an equally big problem is "pollution" of a commonly used namespace as a side effect of importing cmap. For example, any gui program that auto shows all options from mpl would immediately get very ugly, and I don't want cmap to be responsible for that.

   (I know you could have handled this without #162. I was just trying to be accommodating 😊. Ultimately, I feel like this sort of auto registration is application level stuff, not core library stuff. Fine if you want to do it, not something I think cmap should do)

   👍React with 👍1Reacted by Casper van Elteren
10. cvanelteren commented on Oct 21, 2026

    

    cvanelteren

    on Oct 21, 2026

    Author

    More actions

    Ok thanks for clarifying @tlambert03. I will have some deliberation on adding it on our end directly. We do have some overlap of what we bundle already but that need not be a problem. Until next time ;-)!