What about spec.defaults?

The idea is that we are doing (almost) the same as scipy curve fit here, that is, ignoring default values unless they are kwargonly.

Example:

def model(x, a, c=3, *, d, e=5):
    return ...

Let's say x is a coordinate. Then a, c and d will be counted as parameters here in curve_fit.
e will not be counted as a parameter because it is kwargonly and has a default value, and might have been set by partial.
The default value of c will be discarded because it is not a kwargonly argument.

We differ from scipy because we also allow kwargonly arguments without defaults to be counted as parameters. That is, scipy would only have counted a and c as parameters in the above example.

The default value of c will be discarded because it is not a kwargonly argument.

Yes. My question is, why do we do that?

Also see #3465 (comment)

Because that is what scipy does here, and I think it makes sense to try to do the same thing there.

Scipy does not allow keyword-only arguments. And it never seems to respect default arguments. So this argument does not work. We are deviating from Scipy by allowing keyword-only arguments. In the Scipy wrapper, we even require keyword-only arguments.

So my questions are:

• Why would scipp.curve_fit allow positional arguments?
• Why would scipp.curve_fit tread positional and keyword-only arguments differently if both are allowed?

Scipy does not allow keyword-only arguments. And it never seems to respect default arguments.

But it does? Scipy respects kwargonlydefault arguments, but not default arguments.
See here:

from scipy.optimize import curve_fit
curve_fit(lambda x, a, *, b=5: x * a, [0, 1, 2], [4, 5, 6])
# returns 1 parameter value, not 2

It's true that Scipy does not allow keyword-only arguments. Scipy curve_fit will fail on functions with kwargonly arguments without default values.
Scipp doing something different in that case is not a deviation from scipy, more an extension, which I think makes sense in this case.

Answers to the questions:

Why would scipp.curve_fit allow positional arguments?

Why would it not? There's no reason to disallow it, and creating artificial constraints harms usability.

Why would scipp.curve_fit tread positional and keyword-only arguments differently if both are allowed?

Yes I see that this is a bit strange. But I think all the choices here have drawbacks. If we want to always treat positional and keyword arguments the same way we could either:

• respect default (non-keyword) arguments - but this differs significantly from scipy
• only allow parameters to be keyword arguments - makes the interface more cumbersome

scipp.scipy.optimize.curve_fit requires keyword-only args for all but the first argument. Is scipp.curve_fit different? If not, spec.args can be removed here.

Yes scipp.curve_fit is different in that regard.

Please document this behaviour clearly! It is not clear from the signature how model arguments are handled.

given that the defaults are removed below.