The long-term goal is to make colorbar axises as similar as possible to normal axises. Ideally colorbar.locator and colorbar.formatter would just be dumb reflections of what is on the long axis.

@timhoffm thanks for the review! Yes, I agree that the way it is done here is unaffordable breaking change.

What you have to do is accept new style format strings along-side %-style.

So, the idea is to revert the changes and do something like

ifisinstance(format,str):# Check format type between FormatStrFormatter and StrMethodFormattertry:self.formatter=ticker.FormatStrFormatter(format)_=self.formatter(0)exceptTypeError:self.formatter=ticker.StrMethodFormatter(format)else:self.formatter=format# Assume it is a Formatter or None

?

Mapping formatter by a property is a separate topic. I suggest to follow up on this in a separate PR if you are interested.

Yes, I can send other PRs with that however I do not quite understand the whole picture of what it can break etc (some guidance could be needed).

You'll loose the formatter with your approach if you switch the orientation. I'm not quite sure if switching the orientation works at all, but if so that's a de-facto feature that we have to continue to support.

Could you please explain what it the switch of the orientation (with some code if possible) ? Thanks

The long-term goal is to make colorbar axises as similar as possible to normal axises.

Yes, Thomas said something like that during the mentored sprint and that's why I went using property.

So, the idea is to revert the changes and do something like ...

Yes.

Could you please explain what it the switch of the orientation (with some code if possible)

I thought you could swich the orienation by assigning toColorbar.orientation

from matplotlib.ticker import PercentFormatterplt.imshow(np.random.random((3, 3)))cb = plt.colorbar(format=PercentFormatter(), orientation='vertial')cb.orientation = 'horizontal'

but apparently, this does not have any effect.

Yes, I can send other PRs with that however I do not quite understand the whole picture of what it can break etc (some guidance could be needed).

Currently, Colorbar holds the state and pushes the information down to the respective axis when needed; e.g.

This is safe against operations like changing orientation (i.e. long and short axis) or clearing of an axis (I don't know that is happens, but would be ok in the current scenario). If the axis holds the state instead, we have to make sure that it's really kept consistent, which could get messed up if long and short axis are exchanged.
I don't know if any of these are practical problems, but that needs to be investigated if we move the responsibility for the state.

First, I think changing the orientation of a colorbar after creating it is a non-starter, and certainly not something we have done previously.cb.orientation should probably be read-only somehow, but...

For this PR, we have two separate issues that we are looking at:

1. if the user passes "format" to the instantiation, it could accept the "new" formatting specifier: I think this is fine, but we can't stop accepting the old format specifier

2. setter and getter for thecb.format property. This seems helpful in that it is getting and setting from the long_axis. However, I wonder if we also want to rename this so that it is clear that we are really doingcb.set_major_formatter? Or trying to discourage operating on the colorbar directly at all. Where I get confused and have to look carefully each time, is how much formatter/locator logic needs to sit at the colorbar level because of the norm. ie. do we even want users doingcb._long_axis.set_major_formatter()?

Given that these are pretty orthogonal, I agree with@timhoffm that this should maybe be made into two PRs, with 1) being a lot easier than 2)!

@timhoffm@jklymak thanks for the details and the info. I reverted the code and added as proposed in a previous message a way to switch between 2 formatters if input format isstr. Updated also the tests. Please let me know if this is sufficient for the PR "1". Thanks!

Thanks@vfdev-5 ! And thanks for participating in the sprint!

@jklymak I'd like to provide a follow-up PR with setter/getter property forcb.format and maybe other attributes. Should we discuss the scope somewhere in a new issue or I can send a draft PR and we can affine it there ?

I usually prefer a draft PR, even if its just a straw man for discussion, so long as it is not too much work

This should still get a what's new entry.