-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pipe, apply should call maybe_wrap_array, possibly resolve dim->axis #1130
Comments
On I'm OK with calling |
As for
In the unlikely event your function takes a |
It would be just one extra call to a funciton which is very simple. As I commented in #1074, I think it makes more sense to have
I think that could be quite likely as one might want to apply a DataArray-compatible function. This would force users to remember which type of "function applier" to use for a given function and might be confusing. |
It's safe in the sense that the
I think this is unavoidable. It's impossible to design a single entry point that works smoothly for both use cases. |
In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity |
Closing this in favor of #1130 |
While
pipe
andDataset.apply
(btw, why not call them both the same?) specify that they expectedDataArray
returning functions, it would be very convenient to have them callmaybe_wrap_array
anyways.I've often tried piping functions which at first looked like ufuncs only to find out that they forgot to call
__array_wrap__
(I'm looking at younp.angle
). The extra call tomaybe_wrap_array
is cheap, does not break anything and would be very useful. It would greatly enlarge the set of functions that can be readily applied toDataArray
objects without any need for writing function wrappers (motivated in part by #1080).Since many such functions expect an
axis
argument, some syntax fordim -> axis
resolution could be also added. I see some optionsSimple, but specifying
axis='smth'
is not very explicit and may mean something else for certain funcs, it assumes a lot about function signatures.dim
andaxis='dim'
are specified. Still possible conflict of specific meaning, but less likely.Other coding might be possible.
pipe((f, 'arg2', ('axis', dim)), *args, **kwargs)
, but that's getting complicated and less readable.Let me know what you think and perhaps you'll come up with some nicer syntax for dim-> axis resolution.
The text was updated successfully, but these errors were encountered: