minimize does not natively support kwargs like minimize_ipopt, so we have to do some wrapping. This is why the tests heavily emphasize the callable arguments (and I didn't test bounds, options, etc.).

There is one other callable, callback, but that doesn't need to be wrapped because it does not accept additional arguments.

The kwargs haven't ever worked before, I added them in the recent PR #197. If it makes more sense to disable the support for kwargs, we can.

Well, they work now, so no harm leaving them unless you want to deprecate them and remove the parameter altogether.

They don't need to be deprecated because we haven't made a new release yet. If the goal is to match the scipy api, then maybe we should stick to that. Otherwise, I'm open for whatever people need.

I know it didn't work before, but it looks like it was already present as a positional/keyword argument in a previous release (e.g. 1.0.3). For SciPy, that would mean it needs to be deprecated before it can be removed because working user code may pass it as an argument even though it does nothing. But if you are comfortable with the (probably rare) immediate disruption of removing it (e.g. now be an error if it is passed), I understand.

I'd rather not weigh in on that decision, though. (If I had my way, minimize would have neither args nor kwargs, jac would be grad - see scipy/scipy#18249, etc...)

@moorepants since it was already present as an argument in previous releases, do you agree that it would need to be deprecated? In light of that, would you like to just keep it?

I'm fine keeping it, but we should document how we deviate from scipy's minimize function.

I added a bit at the top of the documentation.

Please don't keep kwargs on my account, though. As I mentioned, I am almost always against accepting args and kwargs just to be passed through to functions. I would prefer that standard Python features be used to accomplish the same thing (e.g. def, lambda, or functools.partial to wrap the callable). I've supported them here because whether they worked or not, they have been part of the signature for at least a few releases.

Would you prefer:

?

We'll have to maintain this hard coded list if things change in scipy, so I think I'd prefer the try clause. Is there a reason you hardcoded?

Only to avoid importing from a private module. But I don't think that's much of a concern to me anymore. I'll change it.

approx_fprime doesn't accept kwargs

I'm curious why the tolerances in these checks are quite large.

Think it was because of COBYLA. I'll see if they can be tighter for other methods.

Yeah a few solvers have relative or absolute errors up to the order of 1e-5. I tightened the tolerances to 5e-5 across the board and made them variables so they can be adjusted more easily. I don't think it's worth it to have different tolerances for each part of the test / every method, and 5e-5 is about the tightest we can do and have everything pass.

Ok, that's fine.