Some categorical colormaps are given as list of numerical RGB instead of list of hex strings

[TheoMathurin]

colorcet 2.0.6

The colorcet user guide specifically mentions that it provides 'Bokeh-style' palettes as lists of hex strings, which is handy when working with Bokeh.

However, I realised this was not the case for some of the categorical palettes, including cc.glasbey_bw and cc.glasbey_hv. These return lists of RGB triplets which don't work with Bokeh.

Accessing these palettes by string name (e.g. cc.palette['glasbey_hv']) does yield a list of hex strings... so this is only an issue with regard to consistency.

[jbednar]

I'm not sure what glasbey_rw is, but I can see why it's confusing for glasbey_hv. I think it's actually already consistent, though the consistency may not be obvious:

• The native specification for every colormap (categorical or not) is as a list of numerical RGB values.
  • E.g. for the "fire" colormap, the native values are in colorcet.linear_kryw_0_100_c71, and for "glasbey_hv", the native versions are in colorcet.glasbey_hv. You can see these values in colorcet/__init__.py.
• There is also a Bokeh RGB version that we construct from the native one and make available for every colormap, with an attribute named as b_ plus the name of the native version.
  • E.g. for the "fire" colormap, the Bokeh RGB values are in colorcet.b_linear_kryw_0_100_c71, and for "glasbey_hv" the Bokeh RGB values are in colorcet.b_glasbey_hv

What's confusing is that for some colormaps the usual way to refer to them is through an alias like cc.fire, because the native names are long and unwieldy, and those aliases are to the RGB and not numeric triple version. There's no similarly long and unwieldy name for the glasbey maps, so it is tempting to use the native triple ones directly. Using them directly will work with systems that accept numeric triples, but Bokeh does not, so you need the b_ form.

Short of making Bokeh understand the list of numeric triples, I guess our options are to apologize and point out this issue in the docs, or change the name of the native Glasbey ones to something unwieldy and then use the names like glasbey_hv for the RGB triples. Doing this will break at least some category of users, though, so we have to be sure it's worth doing.

[TheoMathurin]

Sorry I meant glasbey_bw, not glasbey_rw, edited in my post.

Ok I understand the logic behind this, and it explains why on the contrary cc.glasbey_cool for instance (or warm, dark etc) is a list of hex strings: it's the short name for cc.glasbey_bw_minc_20_hue_150_280 and is therefore not the native version.

In my opinion from a user perspective an inconsistency remains, as there is a different treatment for seemingly similar objects with short names (such as cc.glasbey_hv and cc.glasbey_cool). However it can be managed easily so maybe it's not worth considering breaking changes indeed. Udpating the docs may be more appropriate.