feat: add cmap_kwargs to Colormap, to pass kwargs to parametrized colormaps

[alisterburt]

and expose cubehelix with Colormap("cubehelix", cmap_kwargs: dict[str, Any]) API

closes #19

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.56%. Comparing base (e350a28) to head (6d9f5da).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #134      +/-   ##
==========================================
+ Coverage   95.55%   95.56%   +0.01%     
==========================================
  Files         168      168              
  Lines        2181     2186       +5     
==========================================
+ Hits         2084     2089       +5     
  Misses         97       97              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tlambert03]

thanks @alisterburt! love the idea, would prefer to avoid a new registry though... and i think we should be able to avoid it. in the Colormap.__init__, if the value is a str, we can resolve it from the existing catalog:

cmap/src/cmap/_colormap.py

Lines 232 to 234 in 1697c07

	if isinstance(value, str):
	rev = value.endswith("_r")
	info = self.catalog()[value[:-2] if rev else value]

and then info.data itself may be a callable (we don't need to separately track which ones are callable). So, you could perhaps just add another check in the __init__ there:

if cmap_kwargs and not callable(info.data):
    raise ShameOnYou
if isinstance(info.data, list):
    ...
else:
    data = partial(info.data, **cmap_kwargs) if callable(info.data) else info.data
    stops = _parse_colorstops(data)

thoughts?

[tlambert03]

(and that shows that there are many more than just cubehelix)

In [5]: {x.name for x in Colormap.catalog().values() if callable(x.data)}
Out[5]: {'ocean', 'afmhot', 'gnuplot', 'heat', 'flag', 'prism', 'cubehelix', 'rainbow', 'fire', 'gnuplot2', 'grv'}

though, not all of those accept params... which raises the question: when should "bad" params be detected? I would think at init-time... but we might need to force the creation of a small lut to check it

[alisterburt]

thanks for the fast turnaround on review - all makes sense, out and about today but will try to find some time in the coming days to get this over the line

[tlambert03]

I'm also more than happy to do it if you were just opening the PR to be polite and don't care either way :)

[alisterburt]

@tlambert03 sorry for the lack of response here - totally on board with all of your suggestions and unlikely to get to it myself on any reasonable timescale so please clobber at will!