I don't really think#28198 is actually a problem and would leave the behavior as is, but if we're really going to change this (I'm only -0 but nowhere close to blocking) then I'd say that indexing should just be a new operation (cmap[idx] -- which seems best to me -- orcmap.colors[idx], as discussed in the issue thread), not a flag on__call__.

I think#28198 is a footgun that should be removed. Needing the upper-limit color of a colormap is not completely unlikely, and intuition suggestscmap(1). It's completely non-obvious that you need to docmap(1.).

Ideally,Colormap.__call__ would always expect values in the range [0, 1]. But we need indexing capability to support the awkwardBoundaryNorm. While I'd like to get rid of that, the discussion is still open, see#21911, and anyway that'd be a more long-term project.

Since for the time being we need indexing capability, at least I want to make that explict and not decidecall behavior based on the data type. You have two options for this, an additional paramterby_index, or a separate functioncmap.by_index(X, alpha=None, bytes=False)(note that[idx]is not sufficient because we need to support the extra parameters to keep full functionality forBoundaryNorm` use cases).

Theby_index kwarg is the simpler implementation. Aby_index() function would also be possible, but needs more internal rearchitecting of Colormap.