fix passing of curvefit kwargs

[slevang]

• [x] Closes #6891
• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

[TomNicholas]

Thanks for doing this @slevang ! Would you mind adding a tiny regression test too?

[slevang]

Thanks for doing this @slevang ! Would you mind adding a tiny regression test too?

Right, I guess this actually breaks the previous way of passing kwargs and that is why the docs build failed. Hmmm. To go with the current changes, thoughts on adding something like this to the parsing logic:

if kwargs is None:
    kwargs = {}
elif "kwargs" in kwargs:
    kwargs = {**kwargs.pop("kwargs"), **kwargs}

to allow for the desired functionality but also handle the old case when someone passes kwargs as a dict? Feels wonky but it works. Is there a smarter way of doing this?

BTW it took me a minute to figure out what happened here because the docstring in the original PR was actually correct (requiring a dict, albeit maybe not the best way of passing kwargs), but then got changed in #5182 to suggest that kwargs could be passed on their own. I see .interp() behaves the same, where only a dict of kwargs can be provided and passed to the underlying scipy interpolation. So it could be worth generalizing this for other methods where we are passing kwargs to a child function of some sort, to allow both of these patterns.

[headtr1ck]

Is that something that will be deprecated or is it planned to keep the support for the kwargs dict forever?

[slevang]

Is that something that will be deprecated or is it planned to keep the support for the kwargs dict forever?

Not sure if there are any strong opinions here? I don't see much harm in keeping it around but we could also deprecate.

[dcherian]

only a dict of kwargs can be provided

I think we may want to keep only the current behaviour (perhaps add an example to the docstring instead), and have that be consistent across the project when we wrap external functions. It's similar to what we do with apply_ufunc also.

Can someone open an issue to discuss this?