This logic should be in the artist, not in backbend bases.

Just had a realization as I am heading out the door... we are going to have
to double-check exactly how this interacts with scalar-mappables in
mplot3d. z-coordinate display has been implemented in a manner similar to
the x and y displays, but we probably don't want to override that --
rather, we want to complement it.

On Fri, Nov 6, 2015 at 5:04 PM, Thomas A Caswell notifications@github.com
wrote:

This logic should be in the artist, not in backbend bases.

—
Reply to this email directly or view it on GitHub
#5425 (comment)
.

On 2015/11/06 12:04 PM, Thomas A Caswell wrote:

This logic should be in the artist, not in backbend bases.

It looks like the override of Artist.format_cursor_data() should go in
cm.ScalarMappable.

@efiring Then we get into MI territory as cm.ScalarMappable inherits from object and then is used as a mix-in with Artist in the child-classes.

Yes, I know, I'm concerned about that also. An alternative would be to duplicate the format_cursor_data override in each individual mappable class, and I don't see that as an acceptable option. Another alternative is to put the full logic into Artist.format_cursor_data, but I doubt you like that idea any more than I do. ScalarMappable is the logical place for it; I presume there is a way to do it, but I haven't looked to see whether any special tricks or larger changes would be required.

Maybe

class Artist:
    def get_cursor_data(self, event):
        """
        Get the cursor data for a given event.
        """
        try:
            return self._get_cursor_data(event)
        except AttributeError:
            return None

and then have sub-classes provide _get_cursor_data. We can safely provide that from the ScalarMappable side of the inheritance.

Another option is to not provide a default get_cursor_data method. It is currently opt-in to get in the list of things that are hit anyway, filtering on hasattr(art, 'get_cursor_data') might not be a bad idea?

@tacaswell, good idea, but we are mixing up two attributes here because of my error in an earlier comment. The present issue is entirely about format_cursor_data. Your suggestion will work nicely with it. A modification would be to use an optional public attribute, fmt_cursor_data in the subclass, analogous to Axes.fmt_xdata, to allow the user to specify a formatter directly. Only if it is not supplied would the colorbar.formatter be used.

Superseeded by #12459, I think.