A flaw in our plans is that get_cmap take as second lut argument which we do not have a public API to do. There is a private API for this (cmap._resample() via #5283). I think this is show-stopping to get this done for 3.6.

I'm still going to try and get the PR to do all of this done, but am skeptical we want to force it through.

As written in #23668 (review), it's ok to postpone get_cmap to 3.7 if it's too complicated.

Given that we are linking this issue in the What's New, I'd really appreciate it if the issue was edited to explicitly explain what is being deprecated, and what is replacing it. I've been following this peripherally, and even for me, the comment above, cut and pasted from elsewhere, is too vague for me to understand the roadmap, so I fear that our users are not going to understand it either. Or in #23668 or whatever follows from it, lay it out in the what's new and don't refer to a cryptic issue?

@jklymak I've rewritten the "Target state" and "Transition path" paragraphs above. Is that clearer now?

The deprecation was bumped in #24846 for 3.7; this now moves to 3.9 for the final part.

Colormaps can be still accessed in version 3.7.0 using the following syntax: getattr(matplotlib.cm, 'colormap_name', None) or matplotlib.cm.jet. This seems to be the simplest way to use a default colormap without a try/except block. It also does not raise any DeprecationWarnings. Is this syntax discouraged or expected to be deprecated in the future?

Issue #19609 mentions this disambiguity, but does not really address my question.

The deprecation warning says to use matplotlib.colormaps, but there is no file colormaps.py, and my type checker complains "colormaps is not a known member of module matplotlib".
The default colormaps should all be static code, there's no need to do any fancy dynamic stuff that breaks type checkers.

colormaps is a private variable in matplotlib.cm, which is imported to public names in the namespaces matplotlib and matplotlib.pyplot. Nothing dynamic. I would have expected that type checkers can handle this.

Note that matplotlib 3.8 (due out soon) will ship with our own type stubs (for the first time) that will help clarify this to type checkers.

Colormaps in the registry are actually a dynamic set of things, that can be changed at run time (and many such as the <name>_r are generated dynamically as well).

Note that most of this implementation was done before static type checking was a thing in Python, and well I have personally invested time into trying to make it better and more usable, there certainly are still (and will be for the foreseeable future) rough edges of the static type checkability of Matplotlib.

(@timhoffm, I think the lack of a __all__ may be making the type checkers ignore the import, but it is included in the pyi file)

(__all__ is in the version of __init__.py on main, but not for any released version)

Sorry for sending a grumpy message, and thank you for your thoughtful response.

At least PyCharm seems not to be able to pick up the type also on master:

It may be worth reconsidering the setup logic and distribute the CorormapRegistry to matplotlib and pyplot via a function cm._get_colormaps.

Hmmm, my editor integration (powered by pyright), and mypy/pyright cli with default settings at least, are perfectly happy with it:

import matplotlib
from typing import reveal_type

col = matplotlib.colormaps
reveal_type(col)

Mypy cli:

$ mypy test.py
test.py:5: note: Revealed type is "matplotlib.cm.ColormapRegistry"
Success: no issues found in 1 source file

Pyright cli:

$ pyright test.py
/home/kyle/play/test.py
  /home/kyle/play/test.py:5:13 - information: Type of "col" is "ColormapRegistry"
0 errors, 0 warnings, 1 information 

(Editor is literally just inlined version of pyright CLI)

Not sure what pycharm is using to do type checking, but those two are generally considered the biggest ones...

Colormaps can be still accessed in version 3.7.0 using the following syntax: getattr(matplotlib.cm, 'colormap_name', None) or matplotlib.cm.jet. This seems to be the simplest way to use a default colormap without a try/except block. It also does not raise any DeprecationWarnings. Is this syntax discouraged or expected to be deprecated in the future?

Issue #19609 mentions this disambiguity, but does not really address my question.

Re-upping this. I just came across some old code that I'm updating. Is matplotlib.cm.Blues going to break in the near future?

There are no concrete plans to remove matplotlib.cm.Blues in the near future. Though I would not recommend using these. matplotlib.colormaps['Blues'] is clearer, only a bit longer and also works for custom registered colormaps. If we remove this, it will get a regular deprecation period, so you'll have two minor versions of heads up.

I believe this is complete with the merging of #26965.

(Edited) for anyone daft like me to replace:

color_map = mpl.cm.get_cmap(name="cool", lut=100)

you can do the following:

color_map = mpl.colormaps["cool"].resampled(100)

Would have been nice to see deprecation warnings for mpl.cm.get_cmap rather than running into errors after it was entirely removed. Maybe I missed them in which case, ignore the noise.

Yes, it would have been nice... and it seems related to Python choices for default warnings, though:
https://peps.python.org/pep-0565/

Now that we manually enabled DeprecationWarnings, we also found out that distutils is being deprecated.... which we are currently using to account for deprecated APIs...