Did we used to rely on a race condition in drawing to make this test work?

I'm also not seeing in the above code how they ended up coupled.

This one took me a long time to figure out that this one-line fix is all that is needed. If I remove the deepcopy, the scales on the colorbar axes seem to stick around or not get updated appropriately? There are some extra ticks floating around and some spines don't get fully removed. I think there is some state that isn't fully getting cleared inaxes_grid with the way the colorbars are handled there.

I don't think this is the most ideal test with this comment about clearing and overwriting portions of the axes.

# In each row/column, the "first" colorbars must be overwritten by the# "second" ones.  To achieve this, clear out the axes first.

This test bit me again... I just added some new code to connect/disconnect the callbacks when changing the norm on a ScalarMappable that already exists. Now, I'm able to remove theax.cax.cla() call, but I need a brand new ScalarMappable for only this test. I think there is something with the colorbars trying to modify old state here, which is why creating a new instance that has no sharing is what we need.

I still don't 100% follow this test code and haven't taken the time to really investigate it in depth and determine whether this test could be rewritten, or if something else in colorbars should be updated.

I think@anntzer worked on this last, trying to make these colorbar-like objects the same as main-library colorbars.

This still feels like there is something different aboutaxes_grid that I am missing and we shouldn't need to deepcopy the norm on the mappable... My guess is there is possibly a locator or something similar attached toax.cax that needs to be cleared/reset on theax.cax.cla() call above, but I haven't been able to find it while debugging and have spent quite a lot of time on this.

Is there a way to step through a debugger session while keeping the plot window open to see how things move around while stepping into functions?

Not that I know of, but I never use a debugger (probably a bad idea).

I'm still deeply confused by this test. It seems that it intentionally over-rides the axes so I guess the point is to show that 'cax' for both of the axes in a given row / column?

I am not sure what the expected behavior here actual is to sort out how big of a change this is...

I am very confused as well. Ithink what is happening is that on the first pass of colorbar addition to the cax, some locators/formatters get updated and set due to the new callback. Then on the second addition of the colorbar, that state is still hanging around. Rather than deepcopying, I switched the test to remove the callback from the colorbar.

The difference with/without the final commit is that the second colorbar axis has ticklabels showing up. I'm not exactly sure where this state creeps in, so this is a hard one to trace down.

OK, I figured out this problem. This is basically due to the interaction between two points.

First, as discussed during the call, cla() doesn't call Colorbar.remove(), which means that the callback of the first image doesn't get deleted, which it should. Making cla() actually go through each and every artist to call cla() on it may be too expensive, but at least perhaps we can check if there's any colorbar on the axes and properly remove() them.

Still, even knowing that, it was unclear why the first image would overwrite the second colorbar. The reason is because the sequence of events was the following:

• instantiate first image, create associated colorbar.
• instantiate second image, create associated colorbar.
• actually walk the draw tree and draw the images... which has the effect of calling _ImageBase._make_image, which contains the following snippet:

# we have re-set the vmin/vmax to account for small errors# that may have moved input values in/out of ranges_vmin,s_vmax=vrangeifisinstance(self.norm,mcolors.LogNorm)ands_vmin<=0:# Don't give 0 or negative values to LogNorms_vmin=np.finfo(scaled_dtype).epswithcbook._setattr_cm(self.norm,vmin=s_vmin,vmax=s_vmax,                                       ):output=self.norm(resampled_masked)

so here s_vmin and s_vmax were recomputed to take interpolation into account. Unfortunately, this means they may be slightly different due to the rescaling and unscaling, which can be checked by printings_vmin - A.min(), s_vmax - A.max(). One then sees that there's indeed a tiny (1e-16) difference for the first image's norm, which means it'll say, oh, I need to redraw the colorbar; but there's no difference(!) for the second image's norm, so it doesn't redraw itself. A quickfix to confirm that this works is that forcings_vmin = A.min(); s_vmax = A.max() here fixes the issue (but would cause other problems with over/under interaction with resampling; I suspect that the "correct" fix is to temporarily disable emission of callbacks byself.norm just for the call to_setattr_cm.

That was nasty :p

That looks like it did the trick. I disconnected from the callback before this and reconnected after it. I wonder if more fundamentally there should be something within the context manager to remove the callbacks on enter/exit...

I guess we could add adisabling_callbacks() context manager on CallbackRegistry?

withself.norm.callbacks.disabling_callbacks(),cbook._setattr_cm(self.norm, ...): ...

Yeah, that looks pretty clean to me. I'm not sure how much more use it would have in more than this one situation though, so is it worth adding or not...

Lets keep it as a separate issue and implement it later.

Rebased and updated this with the blocked callback feature now.

Why is this not warning anymore?

The previous warning was:

matplotlib/lib/matplotlib/image.py:442: UserWarning: Warning: converting a masked element to nan.  vmid = np.float64(self.norm.vmin) + dv / 2

If I print out the previousim.norm.vmin, im.norm.vmax, they were bothnp.ma.masked, which stems from passing in a fully masked array (np.max(np.ma.array([1, 2], mask=[True, True])) returnsmasked), so here we are callingnp.float64(np.ma.masked). I don't think we wantmasked as vmin/vmax, so this perhaps even helps here... The vmin/vmax turn into(0, 0) now.

Note that the image doesn't change at all, just no warning about norm vmin/vmax anymore.

This is fun second-order behavior change!

• InDon't convert vmin, vmax to floats. #6700 we stop passing vmin/vmax throughfloat on init because it stripped precision of float128
• this broke yt that was expecting this to strip off units so we gotDon't convert vmin, vmax to floats. #6700 to add_sanitize_extrema whichgently passes things through float
• this got updated inMAINT: numpy deprecates asscalar in 1.16 #12478 due to changes in numpy to deprecate np.asscalar
• this PR now passesall setting of vmin/vmax through_sanitize_extrema (instead of previously just on init)
• np.ma.masked.item() == 0 butfloat(np.ma.masked) is np.nan

Previously if you did

im=plt.imshow(np.full((10,10),np.nan),vmin=np.ma.masked,vmax=np.ma.masked)assertim.norm.vmin==0assertim.norm.vmax==0

but if you did

im=plt.imshow(np.full((10,10),np.nan)assertim.norm.vminisnp.ma.maskedassertim.norm.vmaxisnp.ma.masked

(== is nan-like withnp.ma.masked).

I would argue that this is a bug, in the sense that explicitly passing thenp.max(data) and letting us auto-computer the max gave different results.

We also say that if vmin == vmax the result of__call__ will be 0.

This will lead to a subtle behavior change in the case where:

• the user passed us all nan
• let us infer the vmin/vmax
• later updates the array with non-nan values

Previously the user would get all "bad" color, now they will get the "0" color. Given the other difference in behavior of explicitly passing vmin/vmax, the agreement with "if vmin/vmax match -> go to 0", this feeling like a very cornery corner case, and the results already being useless from a communications point of view, I think we can leave this as-is and do not need a further API change note.