Summary

This is a collection of topics on colormaps to improve the API and also to eventually make colormaps immutable.

Tasks

• Deprecate parameter ListedColormap(..., N=...)
  It's beyond the scope of ListedColormap to post-process the given list of colors.
  PR: Deprecate ListedColormap(..., N=...) parameter #29135
• Narrow the type of the colors parameter to ListedColormap to a sequence, i.e. no single colors [MNT]: ListedColormap inconsistencies #28763 (comment)
  PR: Implicitly via Deprecate ListedColormap(..., N=...) parameter #29135, because a single color has only worked when also passing N.
• Fix ListedColormap.monochrome attribute [MNT]: ListedColormap inconsistencies #28763
  PR: Make ListedColormap.monochrome a property #29125
• Add add over, under, bad kwargs to constructor, so that one doesn't have to write ListedColormap(...).with_extremes(...)
  PR: ENH: Add bad, under, over kwargs to Colormap #29460
• Deprecate set_over(), set_under(), set_bad()
  PR: MNT: Pending-deprecate setting colormap extremes in-place #30531
• Change default name of ListedColormap "from_list" to ""
  PR: MNT: Change default name of ListedColormaps #30532
• Separate the APIs for mapping [0, 1] -> color (currently __call__(float)) from lut-element access (currently __call__(int)), because cmap(1) and cmap(1.0) giving different results is surprising [MNT]: Colormaps odd behavior (1 != 1.0) #28198
  Suggestion: Replace BoundaryNorm [ENH]: BoundaryNorm should not need to know colormap length #21911 (comment), which will remove the need for indexing through __call__. Maybe create another way to index into a colormap's lut, in case some users need that functionality.
• Decide whether we can better handle lookup tables resolution for LinearSegmentedColormap
  and possibly deprecated rcParams['image.lut'] - globally tuning that parameter seems unreasonable
  and error-prone