ENH: fix call signature display for np.vectorize during jupyter - #29946

Linting is failing. Can you reflow the help text to 88 or less columns?

Hello! I have re flowed the help text to less than 88 columns (Checked with ruff tool). Thank you!

CC @jagerber48 in case you want to take a look.

Can you check if the signature isn't also a bit of a stretch? I.e. the original signature probably allows passing non-positionally, but **args doesn't really. Although, if y'all think it's a big improvement even if stretching the truth, I don't mind it much.

Can we have screenshots of the tooltip posted here like in the the issue thread? @seberg unfortunately I can't understand what you mean about "a bit of a stretch", **args, and "stretching the truth". I'll try to test on my own if I get the time.

I mean that you can't pass arguments by a=np.arange(10) when the original function does, you have to pass positionally, I believe.

@jagerber48 Here is the screenshot of tooltip before vs after changes :

@seberg I did not understand your comment (Sorry!). But, did you mean that if I test the following function:

@np.vectorize
def vec_foo(a, b, c, d=5):
    return a + b + c**2

Define:

A = np.arange(3)
B = np.arange(3) + 10
C = np.arange(3) + 100

And then try to get the function signature, I should get it properly? If so, here is the image showing these:

Sorry, I meant that the signature looks like you can call the vectorized function with func(a=1, b=2) but I think you have to use func(1, 2) (positionally). So the signature itself is slightly wrong I think, but it is nicer to have it show up in the docs...

Ah, I see! You mean that if the wrapped function only accepts positional arguments, then displaying a signature like func(a, b, c, d=19) might make it look like you can call it as func(a=1, b=2, ...), even though keyword arguments wouldn’t actually work. That makes sense. We could add a note to the documentation clarifying that the displayed signature reflects the wrapped Python function. For built-in functions or positional-only callables, the actual calling convention may differ.

Now, what is the best place to add it? Should we put this warning in the Notes section of numpy.vectorize?

Yeah nvm though, seems vectorize does a crazy dance to support kwargs... I did not expect that.

Ok, this looks good to me. It has the improvements we discussed.

The only thing I don't like is the pesky "Call Signature" line that is wasting space. But per the discussion at #29824, it doesn't seem like it will be easy to remove that. Perhaps that could be out-of-scope for this PR and can be opened as a separate issue after this one is resolved.

Thanks for clarifying, @seberg. Good to know about the keyword argument behavior!
And yes, agreed that the “Call Signature” line seems like a separate concern and can be addressed in a follow-up issue after this PR.

Let me know if there’s anything else you’d like me to adjust before merging.

Hmmmm, I forgot about this. Should we just put this in? I expect the try/except is safe enough.
Are we OK with annotations on the signature being a lie (because input/outputs are now arrays)?

@seberg, can you do something about this PR? I want to submit another PR for a different issue, but I am getting an error saying I have reached the maximum number of open pull requests.

I have updated this issue so as to resolve the merge conflict with the latest main.