Test failures are unrelated so far as I can tell...

If I remember correctly, we decided to make the interfaces consistent since the APIs are so similar.

I don't see a strong argument for consistency here. If the inputs were contradictory that would be a problem, but the allowed contourf levels are a subset of the allowed contour levels. If someone needs to toggle between the two, they just need to use the more restrictive levels.

Thoughts, @ianthomas23?

Thoughts, @ianthomas23?

Personally I'm not in favour of introducing differences between contour and contourf.

The colors argument is not consistent between the two, so filled and unfilled contours are already inconsistent. If this did a big sorting song-and-dance to make this work, I'd agree it's not worth it. But the suggestion here is not so much to introduce an inconsistency, as to allow flexibility the existing code already supports.

I think this needs more documentation as the removal of the order opens up room for ambiguity.

AFAICS:

• If levels and colors are given, the mapping between levels and colors is in that order.
• If colors is not an explicit lists, color values are taken from the cmap, and here the values are internally sorted.

Is that correct?

I think this needs more documentation as the removal of the order opens up room for ambiguity.

AFAICS:

• If levels and colors are given, the mapping between levels and colors is in that order.
• If colors is not an explicit lists, color values are taken from the cmap, and here the values are internally sorted.

Is that correct?

Thats correct, and I think that would be expected behaviour. A color list is an ordered list that goes with the ordered list of levels. A colormap maps from a value to a color, so I think the expected value to use is level.

I've mildly updated the docs to state this. I don't think we need to go overboard with documenting this - I'm not claiming we should encourage this usage, just that I don't think it should fail arbitrarily

From the discussion in #31227

So now that we no longer have the historic limitation, there is no technical problem allowing monotonically decreasing contour levels.

I don't see any issue with supporting monotonically decreasing levels if it's feasible. And then doing it for both contour and contourf keeps (more) API parity.

Not requiring contour to be monotonic I think is also fine.

Yeah, this PR doesn't go as far as allowing filled contourf to be monotonically decreasing. That would require some juggling of the arguments to match the order specified by the user.

There are two developers who have stated that they are against this particular change (allowing discrepancy between contour and contourf).

Just noticed that Scott's comment was edited to include his approval of non-monotonic constraint of contour, so I'll edit my comment to take that part out. There are still two devs that have expressed opposition to this change.

@WeatherGod I've still not understood why breaking "consistency" would lead to problems. I'm all for consistent APIs when they lead to less confusion, cleaner code, or to avoid overly convoluted documentation (probably in that order), but in this case it seems to just be a restriction for consistency's sake.