Is this new behaviour? Or did it get broken in the colorbar overhaul?

No idea. Seems to make sense to have it the "new" way, but maybe I miss something. Should be pretty straightforward to add a keyword argument to enable/disable this if required.

Edit: seems like new behavior, at least compared to the last time someone touched those lines.#20054

Edit 2: seems like the concept of removing the first and last element was introduced in4d1107c (see the_edges method, later simplified and inlined).@efiring close to 16 years ago, but do you remember any design decision here?

So probably we would like to introduce a keyword argument for this? Still, I tend to think that the separators are expected when extending, so maybe it should be on by default?

I also assume that a release note should be included then?

Thinking a bit more about it, it seems like one would like to have the option to disable this. For example if the extend part has the same color as the adjacent block. A good name for the keyword argument?

IMHO it could be sufficient to draw a line if the extent color (i.e. over/under) is different and not draw a line if the color is the same. That should almost always be the desired behavior. We should not unnecessarily bloat our API with options that nobody needs. We can always add a kwarg later if needed.

IMHO it could be sufficient to draw a line if the extent color

I've also come to that conclusion after looking at more examples.

Further, I'm not sure this is needed at all. I think this is new behaviour, and it may break as many people as it helps. If the extend color is the same, it is probably unwanted to have a break; if the extend color is different, there is a clear visual break anyways. So I'm not sure that there is a lot of semantic aid this is giving that's worth changing behaviour? I'm also against all the special flags and duck typing and checks we have for colorbar - its API has really gotten out of hand over the years.

@jklymak I'm unclear whether you agree with my proposal (not configurable but line/no line depends on the colors) or whether you argue for always no line. I agree neither is a question of semantics, but I think my proposal is better from an aesthetic perspective.

I wouldn't add the line...

I never use drawedges, and I don't know what the old behavior was (but see below). But logically, I think that if drawedges is requested, then thereshould be a line at the base of the triangle, regardless of whether the color changes. It's a boundary with a logical meaning, no different from any of the other boundaries, which also might or might not coincide with a color change. The user has said "draw lines at boundaries", so just do it. I strongly oppose putting in color-checking logic or a kwarg. I'm not strongly opposed to rejecting the change entirely and saying "we will leave this minor inconsistency in place", but I think#22864 is a valid issue.

History: quickly looking at4d1107c, I think this is consistent withdrawing edges at the triangle bases. The _edges method is omitting theends of the bar, which would be the triangle tips when there are extensions, or the actual colorbar ends when there are no extensions. The entire colorbar was drawn as a single pcolormesh; the extensions were not tacked on separately. In other words, I think that the current behavior is new, in which case the current PR is fixing a regression.

OK agreed, this was a regression - if you checkout 3.4.2 then you get the extra lines. So a simple fix as proposed here should be correct.

Thanks for the feedback!

Will update the PR to check if the extend parts have different or the same color as well.

@oscargus, to be sure it is clear: There is no point in checking whether the colors are the same or not. The PR will be ready to go with only the code clarification suggested by@timhoffm.

This is ready to merge when you make the change above, right?

Since I messed up and pushed this to the base repo rather than my own and I then changed things to avoid that, I am not really sure how to edit this properly. Hence, I would like to ask for a squash merge.

(Also, the alpha test promised in#23260 (comment) is ideally postponed.)

Ithink the doc build failure is because I pushing this to the main repo. Especially since I didn't change anything related to the docs...

This was a regression from 3.4.2 according to@jklymak, so it should be backported to v3.5.x.

@meeseeksdev backport to v3.5.x