Summary

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

Tasks

• Deprecate parameterListedColormap(..., N=...)
  It's beyond the scope ofListedColormap to post-process the given list of colors.
  PR:Deprecate ListedColormap(..., N=...) parameter #29135
• Narrow the type of the colors parameter toListedColormap to a sequence, i.e. no single colors[MNT]: ListedColormap inconsistencies #28763 (comment)
  PR: Implicitly viaDeprecate ListedColormap(..., N=...) parameter #29135, because a single color has only worked when also passingN.
• FixListedColormap.monochrome attribute[MNT]: ListedColormap inconsistencies #28763
  PR:Make ListedColormap.monochrome a property #29125
• Add addover,under,bad kwargs to constructor, so that one doesn't have to writeListedColormap(...).with_extremes(...)
  PR:ENH: Add bad, under, over kwargs to Colormap #29460
• Deprecateset_over(),set_under(),set_bad()
• Change default name ofListedColormap "from_list" to ""
• Separate the APIs for mapping [0, 1] -> color (currently__call__(float)) from lut-element access (currently__call__(int)), becausecmap(1) andcmap(1.0) giving different results is surprising[MNT]: Colormaps odd behavior (1 != 1.0) #28198
• Decide whether we can better handle lookup tables resolution forLinearSegmentedColormap
  and possibly deprecatedrcParams['image.lut'] - globally tuning that parameter seems unreasonable
  and error-prone