This should solve #1072 and #1444. I've yet to update the tests, but please tell me if this the right way to go, as I have a few questions remaining.
x, y, z
I don't think this works as intended? The fill value is assigned only according to the first axis?
You're right. It works in the 1-d case, but I didn't test the 2-d case. Will fix.
This assignment to z[out_of_bounds] does not work as intended --- z has shape (len(x), len(y)), whereas out_of_bounds has shape (nx,).
Yep, I think some new tests are needed here.
Having fill_value=None signal extrapolation (and having that as the default) could be another alternative --- I think I like it more than having string arguments in bounds_error. Backward compatibility probably should be preserved here.
For class attributes not part of API, I'd personally prefer having an underscore prefix, but I'm not sure existing code should be changed to follow this. Of course, if it's "if undocumented, then private" is another rule.
(For Scipy module and function/class names my preference for _ prefix is stronger, because this helps people to see more clearly what may change in the future, and what probaly not. Case in point: there's loads of code out there importing stuff from Scipy's sub-submodules...)
Personally, I'd find overloading bounds_error easier to read and more explicit ("if a bounds error occurs, then just extrapolate") than overloading fill value (which would signal "if a bounds error occurred, then fill with None"), also because None becomes np.nan when assigned to a Numpy array element.
What to do with the x, y, z attributes? They were entirely undocumented, so can they be removed?
I suppose the x, y, z attributes are not widely used by existing code, so they probably could be removed. On the other hand, at least x and y may come useful in some cases, so there's also a rationale for preserving (and documenting) them.
Re: bounds_error / fill_value --- as long as backwards compatibility is preserved, any sensible approach works here.
Hm, I've been trying to write a test, but I can't import the Scipy I just built; scipy.special complains about a missing symbol zbesh_. Any idea what that could be? I'm running a pretty vanilla Ubuntu 12.04.
rm -rf build, rebuild probably helps.
rm -rf build
gh-353 touched this part of the code, so you may want to rebase
BUG: interp2d would ignore three of its arguments
Also changed the meaning of copy=False to not *promise* a reference
to be stored. The reference/copy is useless anyway.
Revised version merged in c3cc0ee