Add a registry for color sequences

[timhoffm]

Color sequences are simply lists of colors, that we store by name in
a registry. The registry is modelled similar to the ColormapRegistry
to 1) support immutable builtin color sequences and 2) to return copies
so that one cannot mess with the global definition of the color sequence
through an obtained instance.
Note that some details of ColormapRegistry are different and we need
different docstrings so that it's easier to have a separate class and not try
to factor out some common aspects in a base class.

For now, I've made the sequences used for ListedColormaps available
as builtin sequences, but that's open for discussion.

More usage documentation should be added in the color examples and/or
tutorials, but I'll wait with that till after the general approval of
the structure and API. One common use case will be

plt.rc_params['axes.prop_cycle'] = plt.cycler(color=plt.color_sequences['Pastel1')

[tacaswell]

Should we include the list of known keys here?

[QuLogic]

So these are essentially colour palettes? Should they be named colour palettes? And if they are colour palettes, how does that jive with colour palettes in seaborn?

[jklymak]

Yes maybe we should hoist the palette framework to matplotlib? Then in the context of this request we could add named_palette to take the name of a sequential colormap?

I think it may be confusing for us to have a parallel api to seaborn, so if we go a different way we should be very explicit about the differences.

[timhoffm]

seaborn.color_palette() is more a color sequence generator that a registry. That's much more than I had in mind, but we can discuss whether we want that functionality.

seaborn.color_palette(palette=None, n_colors=None, desat=None, as_cmap=False)

Apart from (1) returning some named palettes, it can create a palette:

• by (2) sampling a matplotlib colormap
• by (3) sampling from ‘husl’ or ‘hls’, cubehelix system (less configurable versions of the functions husl_palette, hls_palette, cubehelix_palette)
• by (4) lightening or darkening a base color (see also light_palette, dark_palette)

(5) Additionally, one can choose the number of colors. This is quite nice.

(6) Additionally, one can desaturate the colors. This feels a bit much for the function. One could alternatively have a function desaturate(color_palette(...)) or make a slightly fancier list-like object, so that you can do color_palette(...).desaturate(...).

(7) Additionally, one can turn each of the palettes into a Colormap.

[mpetroff]

colormap -> color sequence

[timhoffm]

Moving to draft until we have decided whether and how far we want to go the seaborn way.

Next actions:

• @timhoffm have a closer look at seaborn and come up with a proposal
• Discussion in dev cal

[tacaswell]

Talked about this on today's call: https://hackmd.io/jd_7FjxNQ4y7XgNknvmvGQ?view#color-registry

The consensus was

1. keep the sequence registry simple as a mapping of str -> sequence of colors
2. do not try to re-use the name palettes to avoid confusion with seaborn
3. as a separate question add a (stateless) function for fabricating color sequences from simple input (in the spirit of seaborn.color_palette()).

[timhoffm]

The existing PR should comply with everything we discussed in the dev call. Marking as ready-to-review.

[QuLogic]

The doc failures are relevant.

[QuLogic]

Do we want to have __contains__ to check for registered sequences?

[timhoffm]

__contains__ is mixed in through the use of collections.abc.Mapping
See https://docs.python.org/3/library/collections.abc.html#collections-abstract-base-classes

[QuLogic]

Ah, I missed the class inheritance.