ERR: stat function kwarg interpretation

[mikeyshulman]

df.max(axi=1) does not throw an error and evaluates to df.max()

[jreback]

these functions accept **kwargs in order to avoid us having to name certain numpy arguments (e.g. out), which are not generally acceptable to pandas. I suppose that we could check if any but certain args are there and raise a nice error message.

As I don't want to have out=None in the signature nor the doc-string.

pull-requests would be welcome

[gfyoung]

I'm not entirely sure how all of these functions are set up, but when I tried taking the **kwargs argument out of just one of the method signatures here, it breaks a ton of tests (about 40). I keep on getting TypeError: stat_func() got an unexpected keyword argument 'out', which trace back to function calls in fromnumeric.py in numpy such as amax(axis=axis, out=out)

IINM it seems that this tolerance for "invalid" arguments is quite ingrained into the codebase, so much so that even the tests seem to allow it.

[gfyoung]

Unless someone can explain otherwise, it seems that the best that can be done is to check whether kwargs is non-empty, after which you can raise a warning like: UserWarning: invalid arguments passed into {insert function name}. Please pass in only arguments listed in the function signature

[jreback]

what u can do is pop out from other kwargs
then if it's not empty raise

iirc out is the only arg that we accept that's not listed (and we don't want it) but allow for compat

[gfyoung]

How about just accepting any arguments that currently break the tests? out is not the only one. dtype is another parameter that breaks at least one test.

[jreback]

yeah that too

[jreback]

the reason iirc I did this in the first place because of the API changes in various versions of numpy and didnt want to have to deal with strict checking in case something was added

[jreback]

I am ok with fine grained checking
I just don't really want them in the signature

[gfyoung]

That's fair. It's too bad that there are so many naming conflicts between the numpy and pandas codebase, for the **kwargs is not even used in the functions, only for compatibility between the libraries. Should **kwargs be included in documentation? I did not realize that this was the reasoning initially.

[jreback]

not sure what u mean by naming conflicts

[gfyoung]

What I meant by "conflict" was that the trace back always kept originating to function calls in the numpy library that evidently must have also been defined in pandas IIUC.

[jreback]

btw we first try to dispatch to bottleneck (if installed), then numpy. things are tested with both.

[jreback]

closed by #12318