Hans Moritz Günther

We currently don't have a matplotlib image backend (images are shown in ds9). Once we have that, it's a trivial change to use surfaces instead. However, do we even want...

Astropy has now a minimum requirement for numpy IN THE BUILDSYSTEM (there is a separate requirement to run it): ``` [build-system] requires = ["setuptools", "setuptools_scm>=6.2", "cython==0.29.36", "numpy>=1.25,

It might still be relevant. NumFOCUS is moving very slowly, but depending on where they land we might or might not go with what they work out; so I suggest...

I think that calls for a module called "sherpified XSPEC alternative model extension" (I suggest `sherpa.astro.shame`. 🤣 ). We would then update our docs to use shame models as much...

I agree with that assessment, but at least we now have an issue to point to if someone asks "why did you not..."

So, the answer might be to remove the `setup`/`teardown` machinery since it's barely used anyway? That simplifies the concept of the models. If we build a cache, it can just...

> I thought I had an issue about this for the XSPEC case but maybe I never created it. It's #767.

> The cache calculation code has not been compared to model evaluation to determine when it's faster. This is technically going ti be a per-model-with-a-particular-set-of-parameters decision. See #767 and even...

That logic should already be in the bokeh backend, the lines https://github.com/sherpa/sherpa/blob/main/sherpa/plot/bokeh_backend.py#L383 has the `@translate_args` decorator, which should translate from 'k' to the generic form. The problem is that main...

I's in https://github.com/sherpa/sherpa/pull/1976 If you build this on top of #1976 (or review that one so it gets merged and rebase) the 'k' problem will go away.