issue_comments

Oh no, the doctest failure is because the test is flaky, this was introduced by me in #7821, see here: https://github.com/pydata/xarray/pull/7821#issuecomment-1537142237 and here: https://github.com/pydata/xarray/pull/7821/commits/a0e6659ca01188378f29a35b418d6f9e2b889d2e. I'll submit another patch to fix it soon, although I'm not sure how. If you have any tips to avoid this problem, let me know.

Hi! I would also like to see this implemented, so I rebased this branch and added a test in #7891.

I updated the type hints now (and also did a rebase just in case).

I implemented the broadcasting for bounds also. I hope it's not too ugly. Do you think the signature for p0 and bounds should be updated to explicitly allow only (tuples of) floats or DataArrays?

I just noticed that the docs for curvefit have some formatting issues, I think it's using single backticks instead of double backticks for code formatting. Should I add those to this PR as well?

Hm the doctest failed because the result is off in the last decimal place. I can't reproduce it, even though I have the same versions of numpy 1.23.5 and scipy 1.10.1 in my env as what the CI says. Anyway, changed it in 3001eaf.

I implemented this for p0 in #7821. I used your idea of passing p0 as part of *args. It's maybe a tiny bit hacky to put two things in *args and then reconstruct them based on the lengths, but not too bad.

I can also do this for the bounds, just didn't have time to do it yet. How do you think the multidimensional bounds should be passed? As a tuple of arrays, or as an array of tuples, or something else? To me, it would make most sense to pass them as tuples of "things that can be broadcast", so that e.g. the lower bound of can be a scalar 0, but the upper bound could vary.

It may appear so but it's not: np.array([xval, yval]) causes ValueError: could not broadcast input array from shape (100,7) into shape (100) (as well as a warning about ragged arrays) when yval is 2D.

Hi,

I see this was ready to merge, but I would like to still comment on the error message a bit.

IMO, it should be emphasized a bit more that the file might not exist, which I suspect happens much more often than a backend missing. I came across this PR after me and a colleague struggled with opening a netCDF file for twenty minutes, trying to install different backends and such, until we realized that there was a typo in the filename we were trying to open.

The error message could be something like:

Error opening {store_spec}: The file does not exist or is not supported by any of xarray's currently installed IO backends {installed}. Consider explicitly ...

It's a small change, but in the current version there is a risk that a beginner who knows nothing about storage backends gets stuck on "did not find a match in any of the installed backends" and goes on a wild goose chase installing packages like we did.