GeezerVison

@timhoffm The implementation here is inspired by your comment #30982 (comment)

I realized _ColorizerInterface fulfills almost all the requirements for a mappable for colorbar, so instead of defining a protocol, It occured to me that it might be easier to simply define a new class that subclasses _ColorizerInterface. This greatly reduces the complexity of VoxelDict. Let me know what you think :)

@trygvrad I just had a quick look. Overall this looks reasonable.

I'm a bit worried on the deep nesting we create here:

class _ColorizerInterface:
class _ColorbarMappable(_ColorizerInterface):
class _ScalarMappable(_ColorbarMappable):
class ColorizingArtist(_ScalarMappable, artist.Artist):

Do we need all of these? Can we answer the questions: What exactly does each class bring additionally to the table? Why can't that functionality live in the parent or child class.

Do we need all of these? Can we answer the questions: What exactly does each class bring additionally to the table? Why can't that functionality live in the parent or child class.

Currently we have

1. class _ColorizerInterface:
   Base class that contains the interface to Colorizer objects from a ColorizingArtist

2. class _ScalarMappable(_ColorbarMappable):
   Legacy interface that may still be in use by third parties. This is available with import matplotlib.cm.ScalarMappable
   I would like to remove this at some point, and the class has a note as to how this can be done.

3. class ColorizingArtist(_ScalarMappable, artist.Artist):
   Base class for all artist that use a colormap

In order to have a mappable that is not an artist, we need all the functionality of _ColorizerInterface and some of the functionality of _ScalarMappable. We can solve this by introducing a new class in the hierarchy, but a better option maybe to simply move some of the member functions from _ScalarMappable to _ColorizerInterface, as you @timhoffm suggest.

I would personally prefer _ColorbarMappable [or something similar] as a name for the _ColorizerInterface with increased functionality, as this describes what this class can actually be used for [input to fig.colorbar(...)].

I don't think there is currently any use case for _ColorizerInterface outside of ColorizingArtist

This sounds reasonable. We can always recreate a _ColorizerInterface at the top of the hierarchy later if needed.

Could you do these architectural changes as a separate PR? I believe it's easier to review/discuss the architecture without the voxels in between.

@timhoffm please take a look at #31039 :)