ENH: add annotation for abs

[unnonouno]

numpy.abs is alias of numpy.absolute. I added its type annotation.

[BvB93]

Considering it's an alias, why not just define it as such?

Suggested change

	abs: ufunc
	abs = absolute

[person142]

Also if we could add a really simple test case to numpy/tests/typing/pass/ufuncs.py that would be great!

[unnonouno]

Thank you for reviewing. Ok, I'll add a test case. BTW, I found that ufuncs.py contain no other ufuncs except sin. Is it Ok to add a test case only for abs, or is it better to add all other ufuncs? (or parameterized test?)

[BvB93]

Is it Ok to add a test case only for abs, or is it better to add all other ufuncs? (or parameterized test?)

I feel it's fine as it is now, especially since the (currently) rather broad ufunc.__call__() signature will make adding proper fail tests somewhat tricky.
Still, if you're interested feel free to add them, be it either in this pull request or another one.

[seberg]

Would it be possible to have tests which check that the typing module is a subset of the public namespace? Or is that unnecessary? We may occasionally remove things from the public API and it would be nice to notice it automatically. E.g. I just merged a try to deprecate np.float, etc. which alias the Python types.

[BvB93]

Would it be possible to have tests which check that the typing module is a subset of the public namespace?

That would be rather tricky, as far as I'm aware there is no straightforward way of importing content directly from a .pyi file.

Besides, if something is removed then one of the typing-related tests is likely to break anyway, especially since a number of them are also executed at run-time for this very reason.

[person142]

Would it be possible to have tests which check that the typing module is a subset of the public namespace?

We had something that did the reverse of that (found things in NumPy not in the stubs) in the stubs repo:

https://github.com/numpy/numpy-stubs/blob/master/runtests.py#L94

(It finds things in the stubs by walking the ast.) Something like that could be adapted into a test (though Python ast is not stable, so that's something to think about).

Regardless of tests, I should add that back over here; it's how I kept issues like #16546 up to date.

[person142]

CI failure unrelated, so merging. Thanks @unnonouno!

[unnonouno]

Thank you!